Онтологии в Информационных Системах

В.А.
Лапшин
Онтологии системах
в информационных
Современный подход
Москва ∙ 2009
Оглавление
Оглавление 2
Предисловие 4
1 Что такое онтология 7
1.1 О чем эта книга . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Определение онтологии . . . . . . . . . . . . . . . . . . . . 14
1.3 Типы онтологий . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Что изложено в книге . . . . . . . . . . . . . . . . . . . . . 30
1.5 Список литературы . . . . . . . . . . . . . . . . . . . . . . 34
2 Различные аспекты применения онтологий 37

2.1 Метафизика онтологии . . . . . . . . . . . . . . . . . . . . 37
2.2 Онтологии верхнего уровня . . . . . . . . . . . . . . . . . . 51
2.3 Методология построения онтологий . . . . . . . . . . . . . 66
3 OWL— язык описания онтологий для Web 90

3.1 Необходимость в OWL . . . . . . . . . . . . . . . . . . . . 90
3.2 Язык XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3 Язык RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4 Идеология OWL . . . . . . . . . . . . . . . . . . . . . . . . 116
3.5 OWL редактор Protege . . . . . . . . . . . . . . . . . . . . 126
3.6 Реализации хранилищ онтологий на основе OWL и RDF . 137
2
4 Ontolingua— Web-сервер библиотек онтологий 142

4.1 Концепция «разделяемых знаний» . . . . . . . . . . . . . 142
4.2 Описание языка KIF . . . . . . . . . . . . . . . . . . . . . . 144
4.3 Ontolingua KIF . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.4 Онтология библиографических данных . . . . . . . . . . . 178
4.5 Онтологический Фреймовый Редактор . . . . . . . . . . . 183
5 Cyc— библиотеки онтологий для AI 195

5.1 Что такое Cyc . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.2 Язык CycL . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
5.3 Система логического вывода . . . . . . . . . . . . . . . . . 218
5.4 Онтология системы Cyc . . . . . . . . . . . . . . . . . . . . 228
5.5 Проект OpenCyc . . . . . . . . . . . . . . . . . . . . . . . . 238
Послесловие 245
3
Предисловие
Развитие информационных технологий последней четверти прошлого

века характеризовалось разработкой технологий баз данных и повсе-
местного их внедрения. В начале этого века, подобные процессы на-
блюдаются в разработке технологий, связанных с онтологическим мо-
делированием. У большинства исследователей уже сформировалось по-
нимание того, что использование библиотек онтологий в организации
информационных процессов в ближайшие десятилетия будет таким же
обычным делом, как использование баз данных сейчас. Между тем, ли-
тература на русском языке об информационных инженерных онтологи-
ях и технологиях их использования практически отсутствует. Данная
книга предназначена восполнить этот пробел.
Книга представляет собой обзор понятий, языков и методов, связан-
ных с применением онтологий в информатике. В книге представлены
наиболее крупные мировые системы и проекты использующие инфор-
мационные технологии, основанные на онтологиях.
Целью автора книги было написание ясного введения в проблема-
тику использования онтологий в информационных системах, в Веб, в
задачах представления и использования знаний, для людей, интересу-
ющихся информатикой и впервые знакомящихся с этой темой.
К сожалению, рассказать о технологиях онтологического модели-
рования так, чтобы это было понятно неподготовленному читателю,
довольно трудно. Дело в том, что для описания знаний1 используется
1 Онтологии, упрощенно говоря, представляют собой описания знаний.
4
много методов, которые требуют довольно объемного предварительного
изучения. Например, наиболее известные текущие реализации систем
построения онтологий основаны на языках исчислений предикатов пер-
вого и второго порядков. Ясно, чтобы понять, как устроена та или иная
система построения онтологий, необходимо сначала иметь понимание
того, что лежит в основе данной системы.
Другое препятствие для быстрого понимания более фундаменталь-
но. Состоит оно в том, что построение онтологии знаний представляет
собой ни что иное, как процесс моделирования этих знаний, т.е. постро-
ения модели мира решаемой задачи. Построение модели— непростой и
требующий определенных навыков процесс. Хорошая модель должна,
с одной стороны, быть достаточно общей, чтобы должным образом от-
ражать представление о мире задачи, а с другой стороны, содержать
все необходимые для решения задачи детали. У неподготовленного чи-
тателя неизбежно будут возникать вопросы относительно того, почему
модель была построена именно таким образом, зачем одни понятия бы-
ли описаны в модели, а другие, кажущиеся важными, наоборот, были
исключены из рассмотрения и т.д. Чтобы должным образом понимать
мотивы, стоящие за тем или иным решением, необходимо некоторое
погружение в предмет.
Процесс построения модели называется концептуализацией . Сам
этот термин говорит о том, что в процессе построения модели выделя-
ются концепты— понятия, лежащие в основе модели, и взаимоотноше-
ния между этими понятиями. Читатель также должен иметь некоторое
понимание того, что такое понятие и как оно выражается формаль-
ным образом. Для прояснения этих вопросов приходится обращаться
к философии. Таким образом, в книге также необходимо дать некото-
рое представление о философских идеях, лежащих в основе процесса
концептуализации.
Наконец, не следует забывать, что книга должна дать представле-
ние о наиболее известных реализациях систем построения онтологий,
т.е. некоторым образом, представлять собой обзор этих систем. Можно
описать каждую такую систему в нескольких абзацах, но к сожалению,
такой небольшой объем информации не даст читателю ничего, кроме
понимания того, что такая система существует. Чтобы дать читателю
более полное представление о системе, нужна целая глава. Таким об-
разом, необходимо погружение в систему.
Книга представляет собой введение в идеи, связанные с понятием
онтологии, а также одновременно является обзором наиболее известных
реализаций систем построения онтологий. Текст книги можно читать
без всякой подготовки. Первая глава представляет собой элементарное
5
изложение основных идей, показывающих необходимость онтологий в
современной инженерной науке. Также, в первой главе приведены при-
меры различных типов онтологий. Начинать чтение книги надо обя-
зательно с этой главы. Чтение остальных глав можно производить в
любом порядке. Книгу также можно использовать как справочник по
системам построения онтологий.
Работа над данной книгой велась при частичной поддержке фонда
РФФИ, грант 09-07-00079-а.
Автор выражает благодарность Евгению Михайловичу Бениамино-
ву за помощь и ценные замечания, высказанные в ходе работы над
книгой. Без этой помощи книга вряд ли была написана.
Москва, сентябрь 2009 года.
6
1 Что такое онтология
1.1 О чем эта книга
Эта книга представляет собой попытку систематически изложить раз-

личные методы применения понятия «онтология» в инженерной нау-
ке. Онтология сейчас модный термин, который используется (к месту
или нет) во многих областях человеческой деятельности. Слово «онто-
логия» можно встретить не только в научных трудах, но и в газетных
статьях или телевизионных передачах. В общем, слово, так сказать, «на
слуху». Но, как и всякое новое понятие, термин «онтология» еще не по-
лучил ясной и четкой интерпретации1 . Данный труд является попыткой
заполнить этот пробел, хотя и не претендует на то, чтобы изложенные
в нем подходы рассматривались, как истины в последней инстанции. В
книге излагается видение, которое сложилось в процессе исследований
в научном коллективе, в котором автор является действующим членом.
В инженерии, «онтологические» методы обычно применяются для
построения моделей процессов. Инженерная модель процесса и есть он-
тология. Точнее, онтология представляет собой описание
этой модели.
Такие описания моделей обычно формальны
, т.е. сделаны на разрабо-
1Среди специалистов до сих пор ведутся дискуссии по поводу терминологии,
связанной с понятием «онтология». В России, в мае 2008 года в г. Звенигород был
проведен симпозиум под названием «Онтологическое моделирование», посвящен-
ный анализу существующих направлений в данной области. Одной из целей этого
симпозиума была попытка достичь договоренности о том, что можно называть он-
тологией, а что нет. Труды симпозиума изданы в [23].
7
танном специально для этих целей языке, конструкции которого всегда
интерпретируются точно и однозначно. Это позволяет сохранять опи-
сание в компьютерной памяти с тем, чтобы в дальнейшем использовать
его в другой задаче или проверить с помощью компьютера, не содержит
ли описание логических противоречий.
На самом деле, задача автоматизированного обмена формальными
описаниями моделей явилась главным побуждающим фактором начала
исследований в области применения онтологий. Рассмотрим области
инженерии, где такие задачи возникают.
Впервые, задача построения формального описания модели возник-
ла в программных системах управления базами знаний. Базы знаний—
это систематизированное собрание фактов, которое управляется раз-
работанной специально для этих целей программой. База реализуется
как экспертная система , т.е. программа, которая выступает в качестве
специалиста-эксперта в некоторой тематике. Например, сейчас очень
популярны экспертные системы в медицине. Такая база знаний содер-
жит такое большое количество медицинских фактов, что один человек
не в состоянии запомнить. Экспертной системе могут быть поданы на
вход результаты анализов крови и программа, сопоставив факты сво-
ей базы знаний, может выдать по результатам этих анализов диагноз
больного. Экспертную систему можно дообучать, добавляя в нее новые
факты. Теперь, предположим, что существуют две такие экспертные
системы, сделанные различными производителями и расположенные в
разных медицинских учреждениях, и министерство здравоохранения
решило создать новую экспертную систему на основе двух существую-
щих. Если бы эксперты были людьми, а не машинами, то все было бы
просто: они бы встретились и рассказали друг другу все, что знают. С
машинами ситуация иная— они друг другу просто так рассказать ниче-
го не могут. Поэтому, необходимо формально описать содержимое базы
знаний каждой экспертной системы с тем, чтобы это описание было по-
нятно программе, которая реализует их объединение. Здесь возникают
следующие затруднения:
1. Надо разработать язык, который был бы понятен каждой из трех
участвующих программ. Этот язык должен быть достаточно фор-
мальным для того, чтобы описания баз знаний (онтологии) одно-
значно интерпретировались машинами.
2. Построить описание содержимого базы знаний на этом языке. По-
нятно, что человек такое описание сделать не в состоянии, так как
он не в состоянии держать в уме содержимое всей базы знаний экс-
пертной системы. Значит, описание должна делать программа.
8
3. По описанию базы знаний, сделанному на разработанном языке,
добавить новые факты в базу знаний третьей экспертной системы.
Это также должна сделать программа.
В полном соответствии с традициями инженерной науки, возникла

мысль стандартизировать язык описания знаний, чтобы больше не тра-
тить усилий на его разработку. Тогда, второй и третий пункты из спис-
ка выше свелись бы просто к написанию переводчиков с внутреннего
языка базы знаний в этот язык, и с языка описания на язык представ-
ления знаний в экспертной системе. Это и было сделано (язык обмена
знаниями называется KIF— Knowledge Interchange Format [19]), но про
то, каким образом это было сделано, мы поговорим ниже в четвертой
главе.
Рис. 1.1: Обмен знаниями между экспертными системами.

Потребность построения описаний моделей возникла также в зада-
че поиска Web-страниц по запросам пользователей. В самом начале
появления Web, поисковые программы просто искали в Web страни-
цы, содержащие текст запроса. Например, если пользователь вводил
запрос «Владимир», то поисковая программа искала в текстах стра-
ниц слово «владимир» и показывала страницы, содержащие это слово
в достаточных количествах. Но, слово «владимир» имеет неоднознач-
ное истолкование. Например, это может быть имя известного человека:
9
«Владимир Путин» или «Владимир Ленин», в этом случае, необходи-
мо показать страницы об этих людях. Также, это может быть название
города Владимир, тогда надо показать страницы об этом городе. Доста-
точно умная поисковая программа могла бы иметь достаточно большую
базу фактов, чтобы «знать» о различных значениях слова «владимир».
Но, это бы ничего такой программе не дало до тех пор, пока создатели
сайтов не предоставили описания содержания своих страниц поисковым
программам. Предположим, что сайт о городе Владимир имеет такое
описание. Тогда, поисковая программа может уточнить у пользователя,
не имеет ли он ввиду в запросе «город Владимир» и, в случае согласия,
вывести на первом месте в списке найденных страниц страницу это-
го сайта вместе с ее описанием. Описания содержимого Web-страниц
представляют собой онтологии этих страниц. Web, в котором страницы
имеют описания их содержимого, называет Умный Web (Semantic Web).
Для построения онтологий необходим специальный язык, который был
бы понятен поисковым программам. Такой язык создан и называется
OWL (Web Ontology Language [10]). Мы подробно обсудим этот язык и
проблематику построения описаний Web-страниц в третьей главе.
Рис. 1.2: Описания Web-страниц для поисковых программ.
10
Построение описания знаний необходимо производить в любой объ-
емной системе управления знаниями. Если разработчики базы знаний
планируют ее пополнение новыми фактами, то для этого важно снача-
ла систематизировать содержание этой базы знаний. Надо выделить в
базе знаний разделы, описать их содержание, а также способы связей
различные разделов между собой. В этом случае, пользователи будут
добавлять в систему новые знания в нужном месте. Например, если
система содержит знания по медицине и по биохимическим процессам,
то во время введения информации о новом лекарстве, необходимо бу-
дет как-то связать знания о том, при каких симптомах применять это
лекарство, со знаниями о том, какие химические вещества содержаться
в этом лекарстве и какое физиологическое действие производит прием
данного лекарства. Для этого, необходимо построить онтологию базы
знаний (т.е. ее описание) и в этой онтологии связать различные разделы
между собой. Тогда, пользователь просто заполнит нужные поля при
вводе информации, и добавленные знания будут связаны в стройную и
логичную схему. Здесь, мы видим, что описание знания играет важную
роль в его систематизации . В главе 5, на примере базы знаний под
названием Cyc [13], мы рассмотрим, как систематизируются объемные
базы знаний.
Рис. 1.3: Онтология как интерфейс к базе знаний.
11
Систематизация знаний— задача совсем не простая. Кроме тех зна-
ний, которые непосредственно содержаться в базе, необходимы еще так
называемые общие знания . Человек о таких знаниях даже не задумыва-
ется, они подразумеваются, как само собой разумеющееся. Например,
человек знает, что люди ходят вверх головой и ногами по земле и, вооб-
ще, то что они ходят есть следствие существования силы притяжения.
Человеку не придет в голову, что можно пройти сквозь стену, пото-
му что он имеет знание о том, что стена— это непроницаемый объект.
Для базы, содержащей только конкретные знания, все эти очевидные
для человека понятия недоступны. Поэтому, родилась мысль о том,
чтобы формально описать основные свойства мира,— так называемые
общие знания, и применять эти знания в различных базах конкретных
знаний. Эти описания обычно называют онтологиями верхнего уровня
(top-level ontologies). Типичная база знаний чаще всего содержит три
уровня знаний:
1. Общие или абстрактные знания, описанные в онтологии верхнего

уровня.
2. Знания о конкретной предметной области (domain specific

knowledge). Например, знания по географии, политологии или ме-
дицине.
3. Конкретные знания, добавляемые в базу знаний пользователями

или программными агентами.
Разделение знаний на уровни вообще свойственно человеку, об этом мы

подробно поговорим ниже в начале второй главы (см. раздел 2.1). Су-
ществуют различные подходы к описанию общих знаний, эти подходы
мы рассмотрим подробнее в разделе 2.2 второй главы.
Сейчас, онтологии применяются во многих областях инженерии.
Выше, мы рассмотрели несколько примеров, где без описания знаний
сделать вообще ничего нельзя. Но, существуют также сферы, где важ-
ность формального описания знаний для машин еще не до конца осозна-
на и, потому, применение онтологических подходов в этих областях вы-
глядит неожиданно. Рассмотрим, например, такую область, как линг-
вистика. Знания о языке в наш век описаны достаточно формально
во многих учебниках и с успехом используются различными специали-
стами. Но, оказывается, и в этой области стали необходимы описания
знаний в удобной для машин форме. Так, известно, что создание ком-
пьютерного переводчика с одного языка на другой,— задача, имеющая
большую важность. Решение этой задачи сэкономило бы человечеству
12
много усилий. Ежегодно, в мире выпускается большое число специали-
стов по переводу, государства тратят на обучение таких специалистов
достаточно объемные средства. Если бы был создан машинный пере-
водчик, то эти средства можно было бы направить на подготовку спе-
циалистов в других отраслях. Для решения задачи автоматического пе-
ревода, стала очевидной необходимость формального описания знаний
о языках. Разработчики предыдущих поколений программ машинного
перевода пытались создать эти программы как обычные приложения.
Создавалась программная модель, логика перевода описывалась про-
граммным кодом, а словарь обычно сохранялся в базе данных. Но, ока-
залось, что знания о языке настолько объемны, что закодировать их
непосредственно в программной модели весьма затруднительно. Кро-
ме того, затруднения имеются в самой формализации знаний о языке—
многие трудноуловимые аспекты этих знаний до сих пор не описаны
формально. В связи с указанными затруднениями, возникла мысль со-
здать описание знаний о языке в машинном формате с тем, чтобы затем
использовать это описание в различных программах, в том числе, и в
программах машинного перевода. Такие проекты существуют, напри-
мер есть проект описания знаний об английском языке под называнием
WordNet [17].
Вообще, как представляется автору, происходящий сейчас процесс
внедрения формального описания знаний в различные области инже-
нерии подобен тому, который происходил в 70-80 годах прошлого века
с базами данных. В 60-х годах прошлого века была осознана необхо-
димость отделения описания данных от самих данных. Описание дан-
ных— это так называемая схема базы данных (концептуальная схема).
Была создана формальная теория таких описаний [см., например, 28]
и, затем, были созданы приложения, которые могли работать с таки-
ми описаниями— так называемые серверы баз данных. Подобные про-
цессы, только относительно описания знаний, наблюдаются и в наше
время. Подобно тому, как введение баз данных позволило заменить ма-
шинами человека (и, тем самым, существенно увеличить объемы обра-
батываемой информации) в различных областях, связанных с обработ-
кой данных, введение онтологий позволит машинам выполнять работу
человека в некоторых областях, связанных с более интеллектуальной
деятельностью.
13
1.2 Определение онтологии
Термин «онтология» не нов и используется в философии уже около

600 лет. Термин был предложен средневековым философом из города
Марбурга Рудольфом Гоклениусом. В 1613 году Гоклениус выпустил
знаменитый «Философский словарь» [2], и там, наряду с термином «ан-
тиномия», предлагался термин «онтология». В 1656 году, этот термин
(в виде эквивалентного термина «онтософия») был применен немецким
философом Иоган Клаубергом в его работе [4] в качестве эквивалента
понятию «метафизика». Позже, немецкий философов Христиан фон
Вольф отделил семантику терминов «онтология» и «метафизика» друг
от друга. Сейчас термин «метафизика» используется для обозначения
раздела философии, изучающего первоначальную природу реальности,
или даже вообще для обозначения всей реальности, выходящей за рам-
ки физического.2 Онтология же стала означать более узкую область
метафизики, посвященную смыслам предметов (понятиям) их взаимо-
отношениям друг с другом.
Слово «онтология» образовано от двух корней древнегреческого
языка: 𝑜𝜈𝜏 𝑜𝜍 — то, что существует (сущее) и 𝜆𝑜𝛾𝑜𝜍 — учение (наука). В
современной философии термин понимается двояко. С одной стороны,
этот термин означает науку о бытие. С другой стороны, термином «он-
тология» обозначают некоторые стороны бытия, которые, как считает-
ся, лежат в основании последнего. Приведем основное определение:
Определение 1.1 Онтология (в философии)— это раздел философии,

изучающий проблемы бытия.
Читатель, вероятно, уже убедился, что понимание термина «онтоло-
гия» в инженерной науке отличается от философского. В инженерии,
понятие «онтология» было сформировано следующим образом. Снача-
ла, была осознана необходимость отделения знаний, которые задаются
моделью программной системы, от поведения этой программной систе-
мы. Затем, на основе этого понимания, сформировалась идея о необхо-
2 Метафизикой в школе Аристотеля называли те стороны бытия, которые не опи-
сывались в аристотелевской «Физике»— труде, посвященном описанию физического
мира и его законов. Существует также и иная точка зрения на происхождение этого
термина. Рассказывают, что в Королевской Библиотеке Лондона книги по «Физике»
Аристотеля стояли на передней полке, а другие его произведения— позади. Древне-
греческий корень «мета» означает «за», отсюда, как говорят, и возникло название
тех трудов Аристотеля, что находились на задней полке. В этом смысле термин
«метафизика» означает «за физикой» в буквальном смысле.
14
димости строить формальные описания знаний программных систем.
Рассмотрим подробнее, как это происходило.
Осознание необходимости отделения описания знаний от самих зна-
ний начало происходить в конце 80-х годов прошлого века. Вместе с осо-
знанием этой необходимости начался пересмотр самого понятия «зна-
ние», применительно к компьютерным интеллектуальным системам.
До этого [36], знание рассматривалось с функциональной точки зре-
ния:
Знание— это нечто, что может быть объяснено (программ-

ному) агенту, чтобы его поведение могло быть вычислено в
соответствии с принципами рационального поведения.
Эта точка зрения выглядит вполне логичной. Если для человека зна-
ние— это прежде всего вера в истинность или, если угодно, в полноту
представлений этого человека о мире (или о какой-то его части), то для
машины понятие веры совершенно не применимо. Поэтому, знание рас-
сматривается как информация, заставляющая программную систему
действовать рационально и предсказуемо. Подразумевается, что эта ин-
формация приходит от некоего эксперта,— человека, обладающего зна-
нием. Позже [27], было предложено рассматривать знание, как модель
представлений о мире, а не модель состояния ума некоего эксперта.
Согласно этому подходу, знание компьютерной системы— это модель
объективной реальности, точнее, некоторой ее части, называемой пред-
метной областью . Но, тогда можно отделить модель описания мира от
поведения программного агента.
Термин «онтология» впервые появился в работе Томаса Грубера
[30]. Грубер решал инженерную задачу создания механизма взаимо-
действия программных систем баз знаний друг с другом. Для решения
этой проблемы были преложены следующие методы:
∙ Выделить в системе управления знаниями уровень так называемо-

годекларативного знания . Это знание о том, из чего состоит мир,
реализованный в данной системе, т.е. декларативное знание пред-
ставляет собой описание данного мира. В противоположность де-
кларативному знанию можно ввести процедурное знание , напри-
мер, знание о том, каким образом на основании описания мира де-
лать логические выводы относительно тех или иных его свойств.
Иначе говоря, предлагалось отделить знание от его обработки.
∙ База знаний предоставляет описание своего декларативного зна-

ния другим программам управления знаниями. Причем, такое
15
описание должно быть понятно, как человеку, так и машине, и
потому, выдается в двух видах:
1. Канонической форме, представляющей собой описание зна-
ния на обычном языке логики предикатов.
2. В форме онтологии , как ее представлял в тот момент Гру-
термов
бер, т.е. в виде набора описаний (классов, отношений,
определений
констант и т.д.) и , связывающих эти термы друг
с другом.
∙ Построить, на основе выделенных описаний, библиотеки онтоло-
гий
, которые можно было бы использоваться в различных базах
знаний.
Таким образом, Т. Грубер является автором термина «онтология» в ин-
женерии.
Задача построения описания знания является довольно специфиче-
ской. Грубер даже выделил для этой задачи отдельный термин— «спе-
цификация концептуализации». Здесь под «концептуализацией» пони-
мается «абстрактный, упрощенный взгляд на мир, который использу-
ется людьми для осуществления некоторой цели» [31]. Особенность за-
дачи концептуализации заключается в том, что для обмена знаниями
между программными системами необходимо явно специфицировать их
концептуализацию, т.е. построить описание этих знаний, причем в до-
статочной степени формальное, чтобы его понимали другие системы.
Результат такой спецификации был назван Грубером термином «онто-
логия».
Таким образом, понятие инженерная онтология можно опреде-
лить как спецификацию (формальное описание) некой концептуализа-
ции (представления предметной области исследуемой задачи так, как
это необходимо для данной задачи). Если со спецификацией здесь все
более-менее ясно, то что такое концептуализация
3
не совсем понятно.
Грубер считал, что концептуализация проводится в терминах классов и
атрибутов. Мир исследуемой задачи представляется в виде понятий, ко-
торые описываются классами, вместе с их свойствами (атрибутами), и
конкретными объектами,— экземплярами классов. Например, проекти-
руя программную систему, содержащую информацию об автомобилях,
естественно ввести классы, представляющие марки автомобилей (Тойо-
та, Лада, Ниссан и т.д.), а конкретные автомобили рассматривать, как
3Следует отметить, что английский термин concept означает ни что иное, как
понятие . Отсюда можно вывести значение термина концептуализация, как постро-
ение системы понятий, отражающей данную предметную область
16
экземпляры соответствующих классов. Такой подход популярен и на
нем основаны принципы объектно-ориентированного программирова-
ния.
Автор полагает, что сведение определения концептуализации к пред-
ставлению только в виде классов и их атрибутов, несколько узко. В раз-
деле 2.1 приводится пример определения понятий посредством так на-
зываемых прототипов — типичных представителей понятия. Так, для
понятия «инструмент» имеется прототип «молоток», а для понятия
«плод» прототипом является «яблоко». Разумеется, у некоторых лю-
дей могут иметься другие прототипы. Например, для понятия «плод»
часто в качестве прототипа называют «апельсин». Это не устанавливает
принципиальных ограничений на использование прототипа, как пред-
ставителя понятия. Таким образом, понятия можно описывать с помо-
щью их типичных представителей— прототипов, и определять, принад-
лежит или нет конкретный объект данному понятию с помощью меры
семантического расстояния данного объекта от прототипа понятия.
Существуют понятия, которые только так и можно ввести. Вопросы,
связанные с различными методами определения понятий подробно об-
суждаются в разделе 2.1.
Концептуализация— это всегда упрощенный взгляд на мир. Из пред-
метной области выделяются только те элементы, которые необходимы
для данной задачи4 , другие свойства предметной области не рассматри-
ваются. Приведем хрестоматийный пример. Пусть, в качестве предмет-
ной области выступает конкретный дом. Для постройки дома задей-
ствуют несколько групп специалистов, среди которые имеются архи-
текторы, поставщики материалов и строители. Архитекторы рассмат-
ривают дом, как единое целое, акцентируя внимание, главным образом,
на том, как различные части (комнаты, этажи) составляют это целое.
Строители также рассматривают дом, как единое целое, но внимание
акцентируется, в основном, на производственных процессах: сколько
человек и какое оборудование отрядить на постройку этажа, сколько
времени необходимо для постройки и т.д. Поставщики материалов во-
обще не рассматривают дом, как единое целое. В представлении постав-
4 Мы будем в таких случаях говорить: цели, а не задачи. Ведь, понятно, что за
каждой задачей стоит некая цель, ради достижения которой эта задача поставле-
на. Человеческий ум устроен таким образом, что он постигает мир только через
упрощенное представление, которое обусловлено некоторой целью. Это представ-
ление называется абстракцией. Например, когда рассматривается конкретный ав-
томобиль, то совсем неважно, скажем, каков этот автомобиль на вкус. Хотя, это
свойство (вкус) определенно присутствует у всех автомобилей, оно в данном случае
(т.е. применительно к понятию «автомобиль») не важно.
17
щика, дом— это вместилище нескольких тон цемента, бетона, стали и
других строительных материалов. Таким образом, цель определяет то,
как будет проводиться концептуализация.
Рис. 1.4: Различные концептуализации объекта «дом».

Термин «концептуализация» использовался Грубером также и для
обозначения процесса построения онтологии. Результат концептуализа-
ции мы будем называть концептуальной схемой . Этот термин исполь-
зуется в базах данных примерно в том же значении, но в частном случае
определения схемы базы данных для некоторой производственной за-
дачи. Имеется, также, некоторое разночтение в терминологии. Выше,
мы определили онтологию, как спецификацию концептуализации пред-
метной области задачи. Но, в философии, термином «онтология» обо-
значается представление реальности в виде набора понятий и связей
между ними, т.е. по сути, концептуализация реальности . В инженерии
производится концептуализация предметной области инженерной зада-
чи, причем цель этой концептуализации, обычно, сугубо утилитарная и
связана с содержанием решаемой инженерной задачи. Таким образом,
имеется явное разделение целей:
∙ Онтология в философии создается для изучения свойств реаль-
ности.
18
∙ Онтология в инженерии создается для решения инженерной за-
дачи.
Это расхождение в целях концептуализации явилось мотивацией для

следующего предложения: термином онтология называть только спе-
цификации концептуализаций реальности, сделанные специально с це-
лью построения такой концептуализации, а все остальные специфика-
ции концептуализаций обозначать термином концептуальная модель
[5]. Соответственно, онтология— это описание реальности в виде фор-
мальным образом специфицированной схемы понятий, а концептуаль-
ная схема— то же, но только применительно к предметной области неко-
торой инженерной задачи. Автору такое разделение кажется излишним,
но конечно, читатель вправе применять эту терминологию.
Для обозначения процесса построения концептуальной схемы ис-
пользуется также термин моделирование . Как уже было сказано выше,
многие специалисты в области инженерной онтологии различают поня-
тия онтологическое моделирование концептуальное моделирование
и
[29; 37; 34].
Приведем точные определения концептуальной схемы и инженерной
онтологии.
Определение 1.2 Концептуальной схемой инженерной задачи назы-

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

ная от простейших таксономий и заканчивая сложными онтологиями,
поддерживающими изменения их содержания.
Классификации
Классификация представляет собой простую форму спецификации кон-
цептуальной схемы, в которой все элементы предметной области раз-
19
Природный мир
Царство
Класс
Отряд
Род
Вид
Разновидность
Таблица 1.1: Элементы Линнеевской Иерархии
биваются на типы5 и между введенными типами вводится отношение

иерархии. Тип является надтипом другого, если класс, который задает-
ся данным типом, содержит все экземпляры класса подтипа. Из опре-
деления отношения иерархии через отношение подмножества следует,
что отношение иерархии транзитивно, т.е. если тип 𝐴 является подти-
пом типа 𝐵 , а тип 𝐵 — подтипом типа 𝐶 , то тип 𝐴 будет подтипом типа
𝐶 . Классификация основана на аристотелевской традиции определения
понятий как коллекций свойств.
Одной из наиболее известных систем классификации является так
называемая Линнеевская Иерархия [6], названная так в честь шведско-
го натуралиста Карла Линнея [1]. Линнеевская Иерархия представляет
собой научную классификацию природного мира. Корневым типом яв-
ляется «природный мир», который изначально был разделен Линнеем
на три подтипа, называемых царствами: «минеральное», «раститель-
ное» и «животное». Сейчас, в биологической классификации царствами
являются восемь подтипов типа «природный мир», мы на них подробно
останавливаться не будем. Непосредственным подтипом типа «царство»
являлся тип «класс». Изначально, в Линнеевской Иерархии имелось
всего шесть классов: млекопитающие, птицы, гады, рыбы, насекомые
и черви. Подтипом класса являлся «отряд», его подтипом— «род», под-
типом рода являлся «вид» и элемент предметной области «природный
мир» назывался «разновидность». Уровень иерархии называется ран-
гом, таким образом, в линнеевской классификации существует шесть
рангов, перечисленных в порядке убывания ранга в таблице 1.1.
Например, элемент предметной области «природный мир» (разно-
видность) Петр Иванов будет классифицирован следующим образом:
5Типы имеют атрибуты. Для типа, значение некоторых атрибутов должно быть
равно одной и той же величине (такие атрибуты называются существенными), а
значения других атрибутов могут быть любыми. Например, можно ввести тип «пря-
моугольник», для которого такие атрибуты, как длина сторон, площадь и т.п. могут
меняться. Но, атрибут «углы» всегда имеет значение 90 градусов для всех углов.
20
царство «животное», класс «млекопитающие», отряд «приматы», род
«человек», вид «человек разумный». Сейчас биологическая классифи-
кация значительно изменилась, появились новые ранги и существенно
расширилось количество признаков (свойств) каждого ранга, но прин-
ципы классификации остаются неизменными.
Для классификации с иерархией типов часто используется термин
таксономия . Таксономия— это классификация, отношение иерархии в
которой может быть представлено в виде дерева типов, т.е. в таксоно-
мии у любого типа не может быть более одного надтипа. У специалистов
по инженерным онтологиями для классификаций часто используется
как синоним новый термин «легкая онтология» (lightweight ontology).
Этот термин очевидным образом подразумевает, что также существуют
и «тяжелые онтологии». Последним термином обозначаются такие он-
тологии, в которых, кроме выделения иерархии типов между элемента-
ми, существуют более сложные связи, выражаемые, обычно, специаль-
ными соотношениями функциями
и . Существует большой класс задач,
для моделирования которых необходимо использовать тяжелые онто-
логии. В этом смысле, моделирование тяжелых онтологий не является
чем-то из ряда вон выходящим. Простые примеры тяжелых онтологий
будут приведены чуть ниже в разделе «Онтологии с соотношениями».
Интересно, что аналогии линнеевской классификации неожиданным
образом проявились в методологии программирования. Одной из наибо-
лее модных на сегодня парадигм программирования является так назы-
ваемое объектно-ориентированное программирование (ООП). В ООП
оперируют объектами, которые представляют собой экземпляры клас-
сов. Класс в ООП— это коллекция атрибутов и методов, имеющая уни-
кальное имя. Атрибут класса имеет тип, а конкретный экземпляр клас-
са заполняет свои атрибуты конкретными значениями. Метод класса—
это некий алгоритм, который может быть вызван для данного экзем-
пляра класса и получает набор конкретных параметров, основанных на
переданных в метод значениях и значениях атрибутов данного экзем-
пляра класса. Между классами можно установить отношение иерар-
хии, используя так называемый механизм наследования . При объяв-
лении типа класса указывается, что он «наследуется» от одного или
более родительских типов, это означает, что все атрибуты и методы
родительских типов являются теперь атрибутами и методами дочерне-
го класса. Очевидно, что такая методология языка программирования
задает описание концептуальной схемы программы в виде классифика-
ции, что упрощает процесс программирования, особенно для объемных
программ, т.к. позволяет разделить элементы программы на модели с
четко выраженным интерфейсом и хорошо специфицированным про-
21
токолом обмена данными между ними. Теория ООП была заложена в
конце 70-х годов и первопроходцем в этом была Барбара Лисков [35].
Ее подход основывался на аналогии с линнеевской классификацией и
из нее же была унаследована терминология.6
Другой известный пример классификации представляет собой Пери-
одическая система химических элементов Д.И. Менделеева [8]. Корне-
вым типом в этой классификации является «химический элемент». Хи-
мический элемент имеет несколько атрибутов, главным из которых яв-
ляется атомный вес . Остальные свойства химического элемента опре-
деляются его атомным весом. Периодическая система не является так-
сономией, так как ее классификация не иерархическая, но основана на
важнейшем понятии «периода». Сущность открытия Менделеева за-
ключалась в том, что с ростом атомного веса химических элементов их
свойства меняются не монотонно, а периодически. После определенного
количества разных по свойствам элементов, расположенных по возрас-
танию атомного веса, свойства начинают повторяться. Например, на-
трий похож на калий, неон похож на аргон, а золото похоже на серебро
и медь. Разумеется, свойства не повторяются в точности, основные или,
как говорят, существенные для данного периода, характеристики оста-
ются неизменными. Таким образом, химические элементы можно клас-
сифицировать по принадлежности к периоду. Кроме того, порядковый
номер химического элемента в периоде также важен: все элементы с
одним и тем же порядковым номером в периоде обладают похожими
свойствами. Так, неон и аргон представляют последние элементы сво-
их периодов и принадлежат семейству инертных газов. Один и тот же
химический элемент, например неон, принадлежит первому периоду,
т.е. типу «первый период», но также и принадлежит и типу «инертные
газы». Следовательно, классификация периодической системы не яв-
ляется таксономией. Это пример более сложного вида классификации,
показывающий, что не все классификации представляют собой таксо-
номии.
Сейчас в системах Web-поиска интенсивно используются классифи-
кации Web-сайтов, в которых описываются иерархически связанные
между собой категории поиска. Обычно, такая классификация пред-
ставляет собой расширенную таксономию, где присутствует дерево по-
исковых категорий, каждый элемент которого может иметь дополни-
тельные свойства. Такая классификация, фактически, представляет со-
6 Этим, вероятно, можно объяснить, что методология проектирования программ-
ных систем в 80-х и 90-х годах страдала, если можно так выразиться, излишним
биологизмом.
22
бой таксономию Интернета, построенную с целью оптимизации поиско-
вых задач. Например, классификация компании «Яндекс» называется
«Яндекс Каталог» [12] и представляет собой дерево не более четырех
уровней иерархии. Типы в этой классификации называются «рубрика-
ми». Существуют следующие рубрики верхнего уровня:
∙ Hi-Tech
∙ Работа
∙ Учеба
∙ Дом
∙ Общество
∙ Развлечения
∙ Отдых
∙ Культура
∙ Спорт
∙ СМИ
∙ Производство
∙ Бизнес
∙ Справки
∙ Авто
∙ Порталы
Подобные классификации существуют во всех популярных поисковых

системах.
Онтологии с соотношениями
Хотя классификации представляют собой наиболее часто встречаю-
щийся вид онтологий, все же существуют задачи, концептуальные схе-
мы которых не укладывается в рамки простой классификации.
Рассмотрим простой пример. Пусть проектируется онтология гео-
метрических фигур и в этой онтологии необходимо описать тип «квад-
рат». Этот тип можно описать двумя способами:
1. Как прямоугольник, у которого стороны равны друг другу.
2. Как ромб с равными углами.
23
В обоих случаях не обойтись простой классификацией, необходимо
как-то задать соотношения между сторонами прямоугольника или уг-
лами ромба.
Вообще, часто типы очень трудно описать простым перечислением
атрибутов. Например, легковой автомобиль можно описать, как авто-
мобиль, масса которого не превышает трех с половиной тонн. Иначе
говоря, легковой автомобиль задается посредством ограничения на зна-
чение своего атрибута. Это наиболее часто используемый тип соотно-
шений.
Существуют и более сложные случаи. Например, понятия «путь»,
«время» и «скорость» в онтологии механического движения связаны
между собой соотношениями, которые выражаются только с помощью
некоторой функции. Для такого рода задач необходимо уметь строить
онтологии, которые выражают более сложные зависимости. И конечно,
для этого необходим специальный язык, который включает эти воз-
можности выражения. Обычно, в качестве такого языка используется
та или иная разновидность языка исчисления предикатов, т.е. опреде-
ляемая онтология представляет собой логическую теорию. В качестве
примера рассмотрим язык Knowledge Interchange Format (KIF) [19], ко-
торый используется в системе Ontolingua [14] в качестве языка опреде-
ления онтологий. Впоследствии (глава 4), мы изучим этот язык более
подробно, здесь только рассмотрим некоторые его идеи, понимание ко-
торых необходимо для усвоения примеров.
Язык KIF фактически представляет собой исчисление предикатов,
содержащее функциональные символы и равенство. KIF базируется на
языке LISP [18], поэтому имеет префиксную нотацию. KIF концептуа-
лизирует предметную область на основе трех основных понятий: «мно-
жество», «отношение» и «функция».
Множество представляет собой абстракцию предметной области, а
именно: считается, что предметная область представляет собой множе-
ство всехобъектов в мире, реально существующих или гипотетических.
Ввиду того, что предметная область в языке KIF представляет собой
абстракцию, разрешается чтобы различные пользователи имели свои
предметные области, однако при этом все такие предметные области
должны включать следующие базовые объекты:
∙ Слова. Иначе говоря, слова являются объектами любой предмет-

ной области, концептуальная схема которой моделируется языком
KIF.
∙ Все комплексные числа.
24
∙ Все конечные списки объектов предметной области.
∙ Все множества объектов предметной области.
∙ Специальный объект, обозначаемый ⊥, который считается значе-

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

нечной последовательностью объектов, которые называются аргумен-
тами , функция ассоциирует некоторый объект, называемый значением
функции. Формально говоря, функция представляет собой множество
конечных списков объектов, которые представляют собой возможные
аргументы функции и последний элемент каждого списка— это значе-
ние функции для данного набора аргументов. Например, функция «2*»
представляет собой множество двухэлементных списков вида ⟨4, 8⟩ или
⟨17, 34⟩, где первый элемент списка— это аргумент функции, а второй
элемент— ее значение.
Отношение представляет собой другой вид связи между объектами
предметной области. Отношение— это произвольное множество конеч-
ных списков объектов предметной области, причем эти списки в общем
случае могут быть переменной длины. Про элементы каждого списка
удовлетворяют
говорят, что они данному отношению или, что отноше-
ниевыполняется на этих элементах. Например, отношение «<» содер-
жит списки ⟨2, 3⟩ и ⟨45, 102⟩, но не содержит списка ⟨5, 2⟩.
Язык KIF описывает онтологию предметной области используя от-
ношения и функции. С помощью этих базовых понятий можно описать
также и типы. Типы представляют собой специальные объекты пред-
метной области. Для выделения типов среди объектов используется од-
номестное отношение «Class». Если данный объект удовлетворяет отно-
шению «Class», то он и считается классом. Но при этом каждый класс
сам по себе представляет одноместное отношение, которое выделяет
множество его экземпляров. Отношения можно связывать друг с дру-
гом с помощью логических операций. Это обычные логические связки
«или» (or), «и» (and) и отрицание (not), а также операция логического
следования (импликация, т.е. если истинно 𝐴, то истинно также и 𝐵 ),
обозначаемая в языке KIF оператором «=>» (𝐴 => 𝐵 ), а также его эк-
вивалентами «=<» (следование в обратную сторону, т.е. 𝐴 =< 𝐵 это все
равно, что 𝐵 => 𝐴), «<=>» (следование в обе стороны, т.е. 𝐴 <=> 𝐵
эквивалентно одновременному выполнению 𝐴 => 𝐵 и 𝐵 => 𝐴). Также
присутствует равенство. Переменные начинаются с символа «?». Язык
KIF мы подробно опишем в главе 4, посвященной описанию системы
25
Ontolingua, здесь же удовлетворим любопытство читателя и приступим
к обсуждению конкретных примеров.
Пример 1.1. (Частичный порядок )
Частичный порядок часто встречается на практике. Типичной явля-
ется ситуация, что некоторые объекты сравнимы друг другом, а другие
нет. При этом, каждый объект сравним с самим собой. Это свойство
называется рефлексивностью . Другие два свойства отношения частич-
ного порядка— антисимметричность транзитивность
и , формально
описаны чуть ниже. Обозначим отношение частичного порядка через
«6». Математически, три его свойства можно выразить следующим об-
разом:
1. Рефлексивность. Для любого объекта 𝑎 выполняется 𝑎 6 𝑎.

2. Антисимметричность. Если 𝑎 6 𝑏 и 𝑏 6 𝑎, то выполняется 𝑎 = 𝑏.
3. Транзитивность. Если 𝑎 6 𝑏 и 𝑏 6 𝑐, то выполняется 𝑎 6 𝑐.
Итак, частичный порядок— это любое двуместное отношение, для ко-

торого выполняются эти три свойства. Можно сначала задать «ре-
флексивное отношение», «антисимметричное отношение» и «транзи-
тивное отношение», и затем определить отношение частичного порядка,
как такое отношение, которое одновременно является рефлексивным,
антисимметричным и транзитивным. Вот как это сделано в системе
Ontolingua:
(defrelation partial-order
(<=> (partial-order ?r ?s)
(and (transitive ?r ?s)
(asymmetric ?r ?s)
(reflexive ?r ?s))))
В соответствии с синтаксисом языка Lisp, функциональные выражения
выражения вида 𝑓 (𝑥, 𝑦) представляются в виде списка (f x y), в кото-
ром первый элемент— это имя функции, а остальные элементы списка
представляют его аргументы. Элементы списка отделяются пробелами.
Для определения отношения используется ключевое слово «defrelation».
Определяется отношение частичного порядка partial-order, задавае-
мое переменной «?r» на множестве «?s». Отношение «?r» является на
множестве «?s» частичным порядком тогда и только тогда, когда оно
26
является на множестве «?s» одновременно транзитивным, антисиммет-
ричным и рефлексивным. Конечно, еще необходимо определить три по-
следних отношения. Приведем, например, определение для рефлексив-
ного отношения:
(defrelation reflexive
(<=> (reflexive ?r, ?s)
(and (binrel ?r, ?s)
(forall ?x)
(=> (member ?x, ?s)
(holds ?r, ?x, ?x)))))
Как и выше, отношение «?r», определенное не множестве «?s», является
рефлексивным тогда и только тогда, когда выполняются одновременно
два условия:
1. «?r» представляет собой бинарное отношение (binrel ?r, ?s), т.е.

имеет всегда два аргумента.
2. Для каждого объекта «?x» (forall ?x) множества «?s»

(member ?x, ?s) выполняется: «?x» сравним с самими собой
(holds ?r, ?x, ?x).
Наверное, единственное что здесь требует комментария, это отноше-

ние «holds», которое используется для проверки того, входит ли список
аргументов в отношение, заданное как первый параметр.
*Изменяющиеся онтологии
До сих пор мы игнорировали тот факт, что онтологии могут изменяться с течением
времени. Примеры онтологий, которые были приведены выше, представляют собой
как-бы снимки концептуальной схемы, которые не отражают ее изменений, проис-
ходящих во времени. Между тем, концептуальные схемы, как правило, изменяются,
появляются новые понятия и исчезают некоторые старые, меняется терминология,
то, что считалось когда-то важным и значительным, со временем перестает быть
таковым, зато то, на что ранее никто не обращал внимания, вдруг обретает особый
смысл и привлекает внимание людей. Хорошо было бы заложить эти возможности
изменения концептуальной схемы в инструмент моделирования, с помощью которо-
го производится построение ее онтологии, чтобы естественным образом эти измене-
ния отображать. Конечно, существуют задачи, когда в самой онтологии задавать
такие возможности нет нужды, проще просто выпустить новую версию онтологии,
отражающую произошедшие изменения. Так, наверное, для рассмотренных выше
классификаций, привнесение в онтологию возможностей ее изменения выглядит из-
лишеством, только затрудняющим понимание основных сущностей. Но для многих
27
других задач, теснее соприкасающихся с реальностью, инструментарий поддержки
изменений несомненно необходим.
Другой факт, который мы игнорировали до сих, состоит в том, что онтологии—
это социальный продукт, т.е. результат коллективного труда. Онтология может со-
здаваться одним человеком, но полезна она только тогда, когда используется дру-
гими людьми. Это означает, что существует договоренность между членами соци-
ума относительно содержания концептуальной схемы, которая строится в данный
момент. Мы говорили о понятиях как о базовых элементах, на которых основа-
но понимание. Но понятия становятся таковыми только тогда, когда оформляется
договоренность между членами сообщества относительно их истолкования. До тех
пор, понятия представляют собой только индивидуальные переживания (смыслы).
Оформление смысла в понятие происходит посредством обсуждения, в процессе
которого понятие уточняется и приобретает четкую форму. Результат такого об-
суждения— это договоренность между членами сообщества о том, каким образом
они соотносят свои индивидуальные переживания друг с другом. Было бы хорошо,
чтобы программная система построения онтологий предоставляла возможности их
коллективного редактирования. Реализация таких возможностей имеет свои труд-
ности и подводные камни.
В процессе изменения типов может меняться и их объем, т.е. могут появлять-
ся новые экземпляры, другие экземпляры могут исчезать. С этой точки зрения,
моделировать тип с помощью множества довольно неудобно, ведь множества опре-
деляются своими элементами, а последние могут быть еще не все известны7 . Чтобы
адекватно выразить свойство неполноты описания типа, необходим соответствую-
щий формальный аппарат. Таким формальным аппаратом представляется теория
категорий [7]. Теория категорий— это раздел математики, оперирующий матема-
тическими конструкциями под названием «категория». Категория содержит два
вида элементов: объекты и морфизмы. Морфизмы выражают связи между объ-
ектами. Так, категория множеств содержит в качестве объектов множества, а в
качестве морфизмов— отображения множеств друг в друга. Каждому морфизму
соответствует два объекта данной категории: объект, ассоциированный с началом
морфизма, и объект, ассоциированный с концом морфизма. Для категории мно-
жеств, где объектами выступают множества, а морфизмами— отображения мно-
жеств, объект, ассоциированный с началом морфизма— это область определения
данного отображения-морфизма, а объект ассоциированный с концом морфизма,
соответственно,— область значений. Традиционно, морфизмы обозначаются строч-
ными буквами латинского алфавита, а объекты— прописными буквами латинского
алфавита (нотация, унаследования от традиционных обозначений множеств и функ-
ций между ними). Будем писать 𝑓 : 𝐴 → 𝐵 для обозначения морфизма 𝑓 с началом
в объекте 𝐴 и концом в объекте 𝐵 . Между морфизмами должна быть задана опера-
ция композиции или умножения морфизмов, а именно: если 𝑓 : 𝐴 → 𝐵 и 𝑔 : 𝐵 → 𝐶 ,
то существует морфизм ℎ = 𝑓 𝑔 : 𝐴 → 𝐶 — композиция морфизмов 𝑓 и 𝑔, где конец
первого морфизма совпадает с началом второго (композицию морфизмов 𝑓 и 𝑔 бу-
дем обозначать как 𝑓 𝑔 или как 𝑓 ∘ 𝑔). Очевидно, что в нашем примере категории
множеств композиция морфизмов совпадает с композицией функций. Морфизмы
7 Поэтому в программах на объектно-ориентированных языках класс— это не
множество: класс определяется именем, а не его элементами. У двух разных классов
может быть в некоторый момент времени, случайно, одинаковое множество извест-
ных элементов (например, пустое).
28
между объектами должны удовлетворять определенным требованиям, а именно:
∙ Для каждого объекта 𝐴 должен быть задан тождественный морфизм
𝑖𝑑𝐴 : 𝐴 → 𝐴 такой, что для любых 𝑓 : 𝐵 ′ → 𝐴 и 𝑔 : 𝐴 → 𝐵 ′′ выполняется
𝑓 ∘ 𝑖𝑑𝐴 = 𝑓 и 𝑖𝑑𝐴 ∘ 𝑔 = 𝑔 . Иначе говоря, композиция тождественного морфиз-
ма с любым другим дает в результате все тот-же искомый морфизм. В точ-
ности так действует тождественное отображение на любом множестве (т.е.
отображение, переводящее каждый элемент множества в него самого).
∙ Композиция морфизмов обладает свойством ассоциативности: если зада-
ны морфизмы 𝑓 : 𝐴 → 𝐵 , 𝑔 : 𝐵 → 𝐶 и ℎ : 𝐶 → 𝐷, то должно выполняться
𝑓 (𝑔ℎ) = (𝑓 𝑔)ℎ. Иначе говоря, композицию трех (а значит, и любого числа)
морфизмов можно брать в любом порядке, в результате получим одну и ту
же стрелку.
Оказывается, любую теоретико-множественную конструкцию можно опреде-
лить с использованием инструментария теории категорий, т.е. через набор объек-
тов, которыми оперирует данная конструкция, и набор морфизмов между этими
объектами. Такие представления бывают весьма неожиданными и зачастую полез-
ны для прояснения данной математической конструкции. Понятие категории лежит
в основе любой теоретико-множественной конструкции, что и определило название
данного математического формализма,— категория служит основанием математи-
ческих построений точно также, как философские категории Канта и Аристотеля
для онтологических теорий этих философов.
В теории категорий можно определить аналоги различных операций над мно-
жествами, такими как декартово произведение множеств или их пересечение. Де-
картово произведение 𝑋 × 𝑌 — это также множество, в данном случае, множество
пар, а значит, объект категории множеств. Для любых двух множеств существует их
декартово произведение, поэтому декартово произведение можно представить как
специальную операцию, сопоставляющую любым двум объектам категории третий
объект. Такие операции носят название универсальные конструкции или пределы.
Для множеств можно определить их декартово произведение, сумму, возведение в
степень и другие операции. Категория, в которой для объектов определены все те
операции, которые определены для обычных множеств, называются топосом. Та-
ким образом, топос представляет собой категорное представление понятия «множе-
ство всех множеств» или, как говорят математики,— «универсума». Объекты топоса
определяются не своим содержанием (как в случае множеств), а взаимоотношением
с другими объектами. Топос хорошо подходит для моделирования онтологий, в ко-
торых понятия задаются с помощью неполных типов. Понятия можно представлять
как объекты некоторого топоса, а различные соотношения между понятиями— в ви-
де морфизмов. Новые понятия могут быть образованы с помощью универсальных
конструкций. Например, пусть в топосе есть два специальных объекта 𝐴 и 𝐵 , первый
моделирует понятие «мужчина», а второй— понятие «женщина». Тогда можно скон-
струировать объект, обозначающий понятие «возможные семейные пары», который
находится с объектом 𝐴 × 𝐵 в специальном отношении, называемом «отношением
подобъекта». Отношение подобъекта— это категорный аналог того факта, что од-
но множество является подмножеством другого. Чтобы ввести понятие «реальные
семейные пары» необходимо построить для этого специальный объект, который из
возможных пар выбирает только те, которые присутствуют в действительности. Для
этого надо использовать элементы объекта — морфизмы из специального конечного
объекта, аналога одноэлементного множества.
29
Иногда бывает, что даже структура топоса не вполне отражает процессы кон-
струирования новых понятий. Рассмотрим, например, конструкцию образования но-
вых понятий методом понятийного смешивания [26]. Понятийное смешивание часто
бывает несимметрично. Например, если имеется два понятия: «лодка» и «дом», то
понятие «дом-лодка» это совсем не тоже самое, что понятие «лодка-дом». С по-
мощью конструкции предела такое несимметричное смешивание выразить трудно,
т.к. пределы симметричны относительно объектов и морфизмов, на основе кото-
рых они конструируются. Поэтому необходимо ввести в определениях понятий воз-
можность выделить главные (обязательные) свойства и модифицировать операции
смешивания понятий с учетом этого выделения. Соответственно, необходимо моди-
фицировать определения математических конструкций, моделирующих операцию
смешивания понятий. Такие попытки уже были проведены Джозефом Гогеном, в
результате появились так называемые 2/3-категории [25; 26].
Онтологическое моделирование на основе формализма теории категорий пред-
ставляет собой отдельную большую тему. В данной книге эти вопросы подробно
затрагиваться не будут.
1.4 Что изложено в книге
Книга посвящена изложению современных систем построения онтоло-

гий в различных областях инженерного знания. Современные подхо-
ды к онтологическому моделированию основаны, главным образом, на
представлении концептуальной схемы на языке исчисления предика-
тов первого порядка, в который добавлены некоторые свойства язы-
ков второго порядка: различные ограничения на свойства отношений
(предикатов)8 . Таким образом, описания наиболее популярных систем
управления онтологиями, данные в книге, тем или иным образом ка-
саются исчисления предикатов. Различные аспекты, связанные с язы-
ками исчисления предикатов, рассматриваются по мере необходимости
их упоминания в изложении описываемых систем управления онтоло-
гиями.
8 Можно ввести ограничения на количество элементов отношения. Например,
каждый человек имеет отца и мать, причем не более, чем одного отца и одной ма-
тери. Если, для указания того, что данная персона имеет в качестве отца конкрет-
ного мужчину, используется двуместное отношение ИмеетОтца (берущее объект
персоны как первый параметр, а объект отца— как второй), то необходимо также
определить и ограничение, выражающее то факт, что одна и та же персона имеет
в точности одного отца. Это можно сделать, указав, что данное отношение долж-
но вести себя как функция, сопоставляющая первому параметру (персоне) второй
параметр (отца). Функция, как известно, не может давать в соответствие каждо-
му своему аргументу более одного значения, поэтому указанное выше ограничения
будет выполняться. В языке OWL отношения с такими ограничениями так и назы-
ваются— функциональные.
30
Первая глава представляет собой расширенное введение в предмет
изложения. В разделе 1.1 излагается мотивация изучения понятия «он-
тология» и приводятся конкретные примеры задач, когда без исполь-
зования онтологий решение этих задач затруднительно. Во разделе 1.2
дается определение онтологии, а также излагаются различные поня-
тия, связанные с этим определением. Раздел 1.3 посвящен изложению
различных типов онтологий. В данном разделе приводятся примеры
классификаций и таксономий, а также более сложных типов онтоло-
гий, таких как онтологии с соотношениями и изменяющиеся онтологии.
И наконец, раздел 1.4 посвящен описанию того, что будет изложено в
последующих главах книги.
Вторая глава представляет собой сборник из трех несвязанных меж-
ду собой разделов. В разделе 2.1 излагаются философские основы по-
нятий, связанных с понятием концептуализации. Здесь излагается в
кратком виде теория прототипа, а также даются основы философского
направления под названием концептуальный релятивизм . На основа-
нии изложенного, дается определение концептуальной схемы, как ре-
зультата концептуализации инженерной задачи. Раздел 2.2 представля-
ет собой обзор известных реализаций программных систем управления
онтологиями. Каждая из таких систем содержит в качестве описания
общих понятий свою онтологию верхнего уровня. Эти онтологию дей-
ствительно представляют собой онтологии, а не концептуальные модели
в терминологии Гуарино [34]. В разделе также дается описание «брил-
лианта Совы»— онтологии верхнего уровня, разработанной известным
американским исследователем Джоном Совой. Онтология дана в ви-
де диаграммы понятий, внешне напоминающим ограненный бриллиант,
отсюда и название. И, наконец, раздел 2.3 представляет собой собрание
различных методологий построения онтологий. Рассматриваются три
методологии:
∙ Методология, предложенная разработчиками языка UML [24], со-

зданного специально для построения моделей программных си-
стем.
∙ Методология, предложенная Грубером в статье «Предполагаемые

принципы проектирования онтологий, используемых для обмена
знаниями» [32]. Эта методология опирается на несколько осново-
полагающих принципов построения онтологий. Изложению этих
принципов и посвящен данный подраздел.
∙ Методология, основанная на так называемом BORO-методе раз-

работки онтологий. BORO (Business Object Reference Ontology)
31
методология [15] была предложена для решения задачи реорга-
низации существующих информационных систем в информаци-
онные модели. В разделе дается описание этой методики и ее ос-
новных принципов.
Глава 3 посвящена изложению языка OWL [10] и связанных с этим

языком концепций. Собственно, языку OWL уделено не так много вни-
мания. Основное предназначение данной главы состоит не в том, чтобы
научить конструировать онтологии на языке OWL, а в том, чтобы по-
знакомить читателя с основными понятиями, которые содержит в себе
этот язык. В разделе 3.1 даются базовые принципы Semantic Web (Ум-
ного Веб), для реализации которого и предназначен язык OWL. Язык
OWL основан на синтаксисе языка XML [11], поэтому в разделе 3.2
дается краткое описание идей этого языка. В разделе 3.3 излагают-
ся основы языка RDF [9], который является ядром для языка OWL.
В данном разделе также описывается язык SPARQL [20] запросов к
RDF хранилищам. Раздел 3.4 посвящен изложению понятий, связан-
ных непосредственно с языком OWL. В разделе дается краткое изло-
жение основ языка, а также различных диалектов языка OWL. В раз-
деле 3.5 описан интерфейс и предложения редактора Protege. Protege
представляет собой редактор онтологий, записанных на языке OWL. В
разделе также дается пример онтологии, записанной на на языке OWL,
иллюстрирующий изложенные в главе идеи. В последнем разделе главы
даются ссылки на некоторые «свободные» реализации RDF хранилищ
с открытыми исходными кодами, которые заинтересованный читатель
может использовать в разработке своих систем.
В главе 4 излагаются различные идеи, связанные с системой управ-
ления онтологиями Ontolingua [31]. Раздел 4.1 посвящен изложению
идей, послуживших побудительным мотивом для создания системы.
Раздел 4.2 содержит описание языка KIF (Knowledge Interchange
Format) [19]. Описание основано на драфте стандарта dpANS [3] языка
KIF. Таким образом, данный раздел можно использовать как неофици-
альную русскоязычную версию стандарта языка KIF. Раздел 4.3 содер-
жит описание той версии языка KIF, которая применяется в системе
Ontolingua. Этот диалект имеет несколько отличий от оригинального
KIF, эти различия описаны в данном разделе. Раздел 4.4 содержит при-
мер онтологии, записанной на языке Ontolingua KIF, приведенный для
иллюстрации изложенных в главе идей. В разделе 4.5 дается описа-
ние Онтологического Фреймового Редактора— инструмента редактиро-
вания онтологий, предоставляемого системой Ontolingua. Фреймовый
Редактор реализован как Web сервер, предоставляющий свой интер-
32
фейс в виде Web-страниц с формами. Описание функциональности это-
го редактора составляет содержание данного раздела.
Глава 5 посвящена изложению идей, реализованных в системе
управления знаниями Cyc [21]. Система Cyc представляет собой базу
знаний, основанную на языке исчисления предикатов первого порядка.
Описанию основных свойств системы и истории ее развития посвящен
раздел 5.1. Для предоставления интерфейса к базе знаний, добавле-
ния новых знаний и их систематизации, в Cyc реализован специальный
язык, названный CycL [22]. Этот язык описан в разделе 5.2. В разделе
5.3 описана система логического вывода, которая используется в базе
знаний Cyc. В системе используется метод резолюций в качестве ба-
зового метода построения логического вывода, но также реализовано
множество эвристических методов, позволяющих уменьшить перебор
вариантов во время выполнения алгоритма логического вывода. Раздел
5.4 содержит описание онтологии верхнего уровня базы знаний системы
Cyc. Как и всякая развитая система управления знаниями, система Cyc
должна каким-то образом их систематизировать. Для этого в онтологии
Cyc описана сложная система общих понятий, а также системы понятий
различных предметных областей, и конкретные знания добавляются в
рамках определенной предметной области. В разделе 5.5 описан про-
ект OpenCyc [16], представляющий собой открытую часть базы знаний
Cyc. База знаний Cyc вообще предоставляется за деньги, но некоторая
ее часть, включающая в себя онтологию верхнего уровня, доступна для
публичного доступа под именем OpenCyc.
33
1.5 Список литературы
1. Бобров Е. Г. Карл Линней. 1707—1778. — Л.: Наука. 1970. — 285 с.
2. Гоклениус Р. Lexicon philosophicum, quo tanquam clave philisophiae

fores aperiunter. Fransofurti, 1613.
3. Драфт стандарта dpANS языка KIF.

http://logic.stanford.edu/kif/dpans.html.
4. . Клауберг И. Metaphysika de ente, quae rectus Ontosophia. Амстер-

дам, 1991.
5. Когаловский М., Калиниченко Л. Концептуальное моделирование

и онтолгические модели. В сборнике Онтологическое моделирова-
ния, труды симпозиума в г. Звенигород, 19-20 мая, 2008.
6. Линней К. Система природы. Царство животных, ч. 1–2. СПб,

1804–1805.
7. Маклейн С. Категории для работающего математика. Перевод под

редакцией В. А. Артамонова. М.:, Физматлит, 2004.
8. Менделеев Д. И., Периодический закон. Основные статьи, М., 1958.
9. Описание концепций языка RDF на сайте W3.

http://www.w3.org/TR/rdf-concepts/
10. Описание языка OWL на сайте W3. http://www.w3.org/TR/owl-

ref/.
11. Описание языка XML на сайте W3. http://www.w3.org/XML/.
12. Сайт Каталога Яндекса. http://catalog.yandex.ru/.
13. Сайт компании Cycorp. http://www.cyc.com.
14. Сайт Онтолингва. http://www.ksl.stanford.edu/software/ontolingua/.
15. Сайт, посвященный BORO методологии.

http://www.boroprogram.org.
16. Сайт проекта OpenCyc. http://opencyc.org.
17. Сайт проекта WordNet. http://wordnet.princeton.edu.
34
18. Сайт языка LISP. http://www.lispworks.com/documentation/common-
lisp.html.
19. Сайт KIF. http://ksl.stanford.edu/knowledge-sharing/kif/.
20. Страница на сайте консорциума W3, посвященная языку SPARQL.

http://www.w3.org/2001/sw/DataAccess/.
21. Страница описания онтологии Cyc.

http://www.cyc.com/cyc/technology/whatiscyc_dir/whatdoescycknow.
22. Страница описания языка CycL на сайте проекта Cyc.

http://www.cyc.com/cycdoc/ref/cycl-syntax.html.
23. Труды симпозиума «Онтологическое моделирование». М.: ИПИ

РАН, г. Звенигород, 19-20 мая, 2008.
24. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользо-
вателя: Пер. с англ.— М.: ДМК, 2000.
25. Goguen J. What Is a Concept?. ICCS, pp. 52-77, 2005.
26. Goguen J, Harrell F. Foundations for active multimedia narrative:

Semiotic spaces and structural blending. Interaction Studies: Social
Behaviour and Communication in Biological and Artificial systems,
2005.
27. Clancey W. The Knowledge Level Reinterpreted: Modelling Socio-

Technical Systems. International Journal of Intelligent Systems, 8: 33-
49б 1993.
28. Codd E. A Relational Model of Data for Large Shared Data Banks.
Commun. ACM 13(6): pp. 377-387 (1970)
29. Fonteseca F., Martin J. Learning the differences between Ontologies

and Conceptual Schemas through Ontology-Driven Information
Systems. Journal of the Association for Information Systems— Special
Issure on Ontologies in the Context of IS. Volume 8, Issue 2, Article 3,
February 2007.
30. Gruber T. R. The role of common ontology in achieving sharable,

reusable knowledge bases. In J. A. Allen, R.Fikes, and E. Sandewell,
editors, Principles of Knowledge Representation and Reasoning –
Proceedings of the Second International Conference, pp. 601-602.
Morgan Kaufmann (1991)
35
31. Gruber T. R. Ontolingua: A mechanism to support portable ontologies.
// Stanford University, Knowledge Systems Laboratory, Technical
Report KSL-91-66, Март 1992.
32. Gruber T. R. Toward Principles for the Design of Ontologies Used for
Knowledge Sharing. International Journal Human-Computer Studies,
43(5-6): pp. 907-928. (1995)
33. Guarino N. Formal Ontology, Conceptual Analysis and Knowledge

Representation. International Journal of Human-Computer Studies,
43(5-6): pp. 625–640. (1995).
34. Guarino N., Formal Ontology in Information Systems. Proceedings of

FOIS’98, Trento, Italy, 6-8 June 1998. Amsterdam, IOS Press, pp. 3-15.
35. Liskov B. Abstraction and specification in program development, MIT

Press, Cambridge, MA, 1986.
36. Newell, A. The Knowledge Level. Artifical Intelligence, 18: 87-127б

1982.
37. Smith B. Ontology. In Floridi L. (ed.) The Blackwell Guide to the

Philosophy of Computing and Information. pp. 155-167. 2003.
36
2 Различные аспекты
применения онтологий
2.1 Метафизика онтологии
В данном разделе будут обсуждены различные вопросы, связанные с

основаниями понятий «концептуальная схема», «онтология» и «концеп-
туализация». Здесь нам придется окунуться в мутные философские во-
ды. К сожалению1 , без философии нам не обойтись. Эта необходимость
продиктована самой природой изучаемого вопроса: термины «понятие»,
«тип» или «класс», а также термин «концептуализация», требуют фи-
лософского обоснования, так как непосредственно адресуют нас к во-
просу о том, как мышление человека соотносится с внешним миром, т.е.
по существу, к основному вопросу философии [36].
С одной стороны, данный труд не представляет собой философ-
ское исследование, поэтому, собственно, философской проблематики
мы в течении повествования постараемся избежать. С другой стороны,
без собственной философской концепции, по крайней мере в вопросах,
непосредственно касающихся нашей темы, не обойтись. Таким обра-
зом, изложение данного раздела представляется автору чем-то сродни
плаванью между Скиллой праведного гнева философов и Харибдой чи-
тательского предубеждения.2 Но, в отличии от легендарного Одиссея,
1 Сожаление выражается, главным образом, так называемым «физикам», т.е.
представителям инженерных специальностей, из которых, как предполагается, со-
стоит большинство читательской аудитории данной книги. «Лирики» же, со своей
стороны, вероятно найдут для себя этот раздел наиболее интересным.
2 Скилла (Сцилла) в древнегреческой мифологии— это чудовище о шести голо-
37
автор надеется все же преодолеть этот непростой путь.
В классической философии, при обсуждении проблематики онто-
логии бытия, обычно рассматривались, если так можно выразиться,
объективные его стороны. В новой философии рассматриваются также
и субъективные аспекты этой проблематики. Иначе говоря, важно не
только то, что представляет собой бытие, но также и как
оно рассмат-
ривается. Обычно, эти вопросы возникают в процессе изучения опреде-
ленных социальных групп. Из наиболее крупных таких общественных
формирований можно назвать народ (этнос). Предполагается, что каж-
дый народ в той или иной степени имеет свое представление о бытие,
в чем-то совпадающее с представлениями других народов, хотя вуль-
гарный взгляд состоит в отрицании такого субъективизма вообще. Со-
временная ситуация такова, что многие народы восприняли культуру
европейской цивилизации, поэтому различия в представлениях о бытие
у разных народов сейчас незначительны. Однако, и в наше время су-
ществуют народы, которые, по тем или иным причинам, не знакомы с
европейской культурой, и тогда различия становятся видны в полной
мере. В этой связи, замечательный пример приводит Д. Дэвидсон [3]:
Уорф, желая продемонстрировать, что язык хопи заключает

в себе метафизику, настолько чуждую, что не может «быть
сверен» с английским, использует последний для передачи
содержания предложений языка хопи!
Идею о том, что существуют особенные представления о бытие,

можно назвать концептуальным релятивизмом [3]. Мы расширим об-
ласть применения концептуального релятивизма, увязав субъективизм
рассмотрения бытия с более мелкими социальными группами, форми-
рующимися для решения какой-либо инженерной задачи. Предполага-
ется, что решающая данную задачу группа, смотрит на бытие под своим
особым, обусловленным целью данной задачи, углом зрения. Эта точ-
ка зрения выделяет из области рассмотрения необходимые только для
данной задачи детали и объекты, а все остальное игнорирует. Получа-
ющееся особое представление о реальности можно назвать онтологией
социальной группы, связанной с данной задачей, или, абстрагируясь от
конкретной группы, онтологией задачи
. Данный труд посвящен изуче-
нию онтологий инженерных задач, а в частности, различным способам
их формального описания. Но, прежде чем перейти к рассмотрению
вах, постоянно оглашающих округу невыносимым визгом и лаем. Харибда не имела
личностного воплощения и представала в виде водоворота, коварно засасывающего
корабли путешественников
38
этих способов, необходимо выяснить что, собственно, представляет из
себя каждое такое особое специфическое представление о бытие, из че-
го оно состоит и каким образом структурируется. Для ответы на эти
вопросы обратимся к философии, в частности, к тому, каким образом
философы представляют структуру онтологии бытия, рассматривае-
мой в ее объективных аспектах.
Наверное, первым источником для формирования понимания о
структуре бытия можно назвать язык. На языке люди общаются между
собой и, в частности, формируют описания интересующих их областей
бытия. Язык состоит из слов, т.е. дискретен. Поэтому, слова можно на-
звать первичными элементами, посредством которых люди описывают
свое представление о бытие. Заметим, что одно и то же слово может
обозначать разные предметы. Например, слово «стул» может обозна-
чать множество разных вещей, рассматриваемых единообразно с точ-
ки зрения их функционального предназначения. Таким образом, слово
«стул» на самом деле обозначает не одну вещь, а целый класс (мно-
жество) вещей. Термин «класс» будем в дальнейшем использоваться
нами именно в этом качестве. Если задаться вопросом, на каком осно-
вании данная вещь соотносится с данным классом, то мы придем к тер-
мину «тип». Типом будем называть отличительные особенности вещи,
на основании которых мы соотносим данную вещь с данным классом.
Предполагается, что эти отличительные особенности одинаковы у всех
вещей данного класса, если их рассматривать с определенной точки
зрения. Здесь следует учитывать, что вещи имеют типы, на основа-
нии которых они формируются в классы, только в предположении, что
существует какая-то точка зрения, обусловленная некоторой целью, в
свете которой вещи приобретают определенную специфику. Так, если
бы мы рассматривали бытие не с целью выбрать вещи, чтобы на них
сидеть, а например, с целью того, чтобы их сжигать, то железные и
деревянные стулья принадлежали бы разным классам. Бывает одна-
ко, что разные цели связаны между собой— одна цель является частью
другой. Например, я хочу подобрать себе в квартиру набор необходи-
мых для проживания предметов. Для того, чтобы сидеть мне нужен
стул, чтобы есть, необходимо куда-то ставить еду, значит нужен стол,
чтобы спать необходима кровать. Все вещи здесь рассматриваются с
функциональной точки зрения, но функции каждой вещи различны,
хотя и в чем-то схожи. Чтобы назвать все такие вещи одним термином,
я использую слово «мебель». Таким образом, возникает новый класс ве-
щей, который содержит класс, который обозначается термином «стул».
Таким образом, классы, а значит и типы, соответствующие этим клас-
сам, могут образовывать иерархию, где каждая вещь более конкретного
39
класса является также и вещью более общего класса. Можно сказать
и так: цель рассмотрения формирует иерархию классов и соответству-
ющих им типов. В самом приближенном виде, такую иерархию можно
считать формой представления бытия, и это представление формиру-
ется на основе цели задачи, с точки зрения которой это рассмотрение
производится. Но, конечно, только иерархией типов вещей дело не огра-
ничивается, кроме отношения иерархии между типами могут существо-
вать другие виды соотношений и часто эти соотношения весьма сложны
и запутаны. Определяемую целью задачи точку зрения на бытие будем
также называть контекстом рассмотрения .
Рассмотрим терминологию, связанную с описанным в предыдущем
абзаце подходом к структурированию онтологии задачи. На основе вве-
денных ниже терминов мы будем строить дальнейшее повествование.
Класс
Как уже говорилось выше, класс представляет собой совокупность ве-
щей, рассматриваемых одинаково с точки зрения цели задачи, для ко-
торой производится рассмотрение. При этом задача принадлежности
данного объекта данному классу может быть в некоторых случаях оче-
видной, может оказаться очень сложной и требующих глубоких иссле-
дований, а иногда размытой и не позволяющей однозначного решения,
но являющейся предметом договоренностей.
Тип
Тип представляет отличительные особенности вещей. Вещи объединя-
ются в данный класс на основе цели задачи, для которой производит-
ся рассмотрение. Эти отличительные особенности одни и те же у всех
вещей данного класса, иначе вещи не были бы соотнесены с одним и
тем же классом. Вещи сами по себе не имеют типов, но типы вещей
появляются только при рассмотрении их под определенным углом зре-
ния, определяемым целью данной задачи. Типы обычно организуются
в иерархию, в которой вещи более конкретных типов являются также
и вещами более общих типов. Используется также терминология тип-
подтип.
Понятие
Понятие— это тип, если его рассматривать безотносительно к точке зре-
ния рассмотрения и особенностей вещей, определяемых данной точкой
зрения, которые представляет данный тип. Такой подход имеет смысл,
40
например, в математических моделях, в которых исследователь обычно
абстрагируется от целей задач и рассматривает различные возможные
соотношения между понятиями безотносительно к тому, зачем они бы-
ли введены.
Поясним введенные выше определения на простом примере. Рас-

смотрим понятие «заяц». Сам термин «понятие», который мы сейчас
употребили, говорит о том, что «заяц» рассматривается сейчас от-
влеченно, т.е. безотносительно какому-либо контексту. Итак, мы го-
ворим «заяц»— это «понятие», если говорим о зайце в общем, вне
какого-либо контекста, и следовательно, не имеем необходимости это
понятие каким-либо образом уточнить.
Тип, если можно так сказать, представляет собой уточненное поня-
тие, которое уже погружено в некий контекст и, следовательно, имеет
свойства, отличающие его от других понятий этого контекста, и свя-
зи с другими типами этого контекста. Например, тип «заяц на охоте»
отличается от типа «заяц в зоопарке» различными свойствами и соот-
ношениями с другими типами. Для типа «заяц на охоте» будут важны
такие свойства, как его скорость бега, умение запутывать следы, а так-
же связи с типами «человек», «собака», «лиса» и другими охотниками.
Для типа «заяц в зоопарке» вышеперечисленные свойства уже не важ-
ны, но важны, например, такие свойства, как «покладистость характе-
ра», «красота», «устойчивость к инфекции» и т.п. Класс представляет
собой совокупность экземпляров данного типа. В нашем случае, это
могут быть зайцы в зоопарке или зайцы в лесу.
Класс— это не множество, т.к. все экземпляры класса не всегда из-
вестны (если сколько зайцев в зоопарке еще можно уточнить, то по-
нять, сколько зайцев в лесу уже проблематично). Хрестоматийный при-
мер— класс страусов за полярным кругом. Можно сказать с большой
долей вероятности, что этот класс пуст, но в этом нельзя быть до кон-
ца уверенным, ведь никто не может поручиться, что на проплывающем
где-нибудь в ледовитом океане корабле не находится какой-нибудь за-
валявшийся страус.
Категория
Отличительной особенностью типов является то, что в зависимости от
целей задачи, они сами могут организовываться в классы. Тогда типам
приписываются новые типы, на основе которых производится объеди-
нение в классы, т.е. типы в контексте данного рассмотрения начинают
выступать как вещи. На этом свойстве типов основано введение новых
41
математических конструкций. Понятие «геометрия» в новом контек-
сте рассмотрения становится вещью— евклидовой геометрией, одной из
многих возможных геометрий. Тип группа, который представляет от-
личительные особенности таких вещей, как целые числа, невырожден-
ные матрицы и перестановки элементов, становится вещью в теории
алгебр. В философии с онтологией бытия также связывается иерархия
типов. На самом верху этой иерархии находятся наиболее общие типы.
Если тип является подтипом другого, то его можно так и определить:
такой-то тип
представляет собой некоторый тип
с дополнительны-
ми особенностями. Это обычный способ определения одного понятия
посредством более общего. Для наиболее общих типов такой вид опре-
деления не представляется возможным. Такие понятия обычно назы-
ваются категориями
. Какие конкретно понятия считать категориями,
зависит от конкретной философской концепции. Впервые термин «ка-
тегория» появился у Аристотеля, который выделил десять категорий.3
Позже этот термин использовался Кантом в его «трансцедентной ло-
гике» для обозначение так называемого априорного знания. По Канту
[8], мир ощущений и восприятий представляет собой хаос, беспорядоч-
ное нагромождение чувств и событий, и упорядочивают его априорные
формы чувственности, такие как пространство и время. Пространство
и время не существуют в реальном мире, но представляют собой только
формы восприятия внешнего мира. Так как пространства и времени не
существует в реальности, знание о них не может быть получено из опы-
та, который предшествует любому опыту и, следовательно, является
априорным. Наложение связей на воспринимаемые сквозь призму про-
странства и времени явления происходит посредством так называемых
категорий рассудка. К таковым можно отнести категории количества,
такие как единство, множество и цельность, категории качества: реаль-
ность, отрицание и ограничение и т.д. Недостаток категорий рассудка
у Канта состоит в том, что они не выводятся из деятельности рассудка,
а довольно произвольно задаются самим Кантом. Этот недостаток раз-
решается в философии Гегеля с помощью диалектики, через которую
Гегель «выводит» категории рассудка из самого бытия.
Смысл
Под смыслом будем понимать психологический феномен, специфиче-
ское состояния ума, которое можно также выразить термином «пони-
мание». Но понимание характеризует это состояние вообще, а смысл
3 Категории Аристотеля мы рассмотрим подробно позже, в разделе 2.2.
42
связан с конкретной вещью. Иначе говоря, смыслом вещи называется
определенное состояние ума конкретного индивида, выражаемое в спе-
цифическом психологическом состоянии этого индивида, которое мож-
но выразить фразой «я понимаю».
Значение
Значения— это смыслы, которые различные индивиды примерно одина-
ково соотносят с данной вещью (как правило, это достигается в резуль-
тате договоренности). Значения представляют собой абстракции смыс-
лов,— понятия, которые выделены из контекстов индивидуальных пе-
реживаний.
Объект
В зависимости от контекста рассмотрения, объект может представлять
собой как тип, так и некоторую вещь. Обычно, термин «объект» ис-
пользуют для выделения некоторого индивида области рассмотрения,
не специфицируя при этом является ли он вещью или типом.
Экземпляр
Экземпляры— это элементы некоторого класса. Обычно экземпляры—
это вещи, но как уже говорилось выше, в другом контексте рассмотре-
ния типы вещей могут рассматриваться как вещи.
Мы пока не выясняли, что конкретно представляют собой отличи-

тельные особенности, на основе которых вещи объединяются в классы,
каков механизм сопоставления вещи ее типу и какова вообще структу-
ра типа. Ответ на этот вопрос также был предложен еще Аристотелем.
Согласно Аристотелю, каждому типу соответствует набор его специфи-
ческих свойств признаков
( или атрибутов
).4 Атрибуты представля-
ют собой различные характеристики вещи, важные в данном контексте
рассмотрения. Атрибуты делятся на существенные несущественные
и .
Существенные атрибуты— это такие свойства вещи, которые позволяют
определить, к какому классу принадлежит данная вещь, т.е. отличи-
тельные свойства данного типа. Несущественные атрибуты— это свой-
ства, которые имеют все вещи данного типа, но которые не участвуют
в соотнесении вещи данному классу. Например, для понятия «ябло-
ко» существенными свойствами будут: плод
(происхождение), круглый
4В дальнейшем, если это не будет оговорено особым образом, термины «свой-
ство», «признак» и «атрибут» будут считаться синонимами.
43
(форма), вкус (нечто общее для всех яблок) и некоторые другие. Несу-
щественными свойствами будут цвет (яблоки бывают разных цветов),
размер (есть райские яблоки, похожие на ягоды) вес и другие. Популяр-
ный в настоящее время объектно-ориентированный подход к програм-
мированию также построен на аристотелевской традиции. Например,
в языке программирования C++ типы задаются с помощью ключево-
го слова class, за которым идет перечисление типов и имен атрибутов
класса, а также его методов. Конкретный экземпляр данного класса со-
держит конкретные значения свойств-атрибутов и, фактически, пред-
ставляет собой ни что иное, как совокупность своих свойств. Здесь сле-
дует отметить, что существенные свойства типа в конструкции класса
языка C++ не задаются, так как всегда имеют одни и те же значения
для всех экземпляров класса. Эти значения содержаться во всех клас-
сах в качестве фиксированных значений соответствующих атрибутов
родительского класса. Аристотелевская традиция задания типов вещей
является в наше время основной, но существуют также и принципиаль-
но иные подходы для задания типов.
В 70-х годах прошлого века в когнитивной семантике был предложен
другой подход. Его автором считается Элеонора Рош (Eleanor Rosch)—
профессор психологии из Бэркли (Калифорния). Теория, описывающая
данный подход к различению понятий, называется теория прототипа
[см. 65; 66; 68]. Основная идея этой теории основывается на предполо-
жении, что каждый тип имеет по крайней мере одного характерного
представителя, который называется прототипом данного понятия. То-
гда, принадлежит или нет данная вещь данному типу, можно проверить
степенью похожести этой вещи на прототип данного типа. Конечно, для
каждого понятия еще надо выделить его прототип и большая проблема
определить является ли данная вещь типичным представителем данно-
го типа или нет. Рош предлагает следующие признаки того, что данная
вещь является прототипом понятия:
1. Время ответа. Время ответа на вопрос назвать вещи данного ти-
па гораздо быстрее для прототипа данного понятия, чем для нети-
пичных элементов.
2. Предварительное связывание. Если предварительно связать субъ-
екта с некоторым понятием более высокого уровня, то распознава-
ние того, что два слова являются одинаковыми происходит быст-
рее. Например, если сначала показать табличку с надписью «ин-
струмент», то распознавание того, что на двух далее показанных
табличках написано одно и то же слово «молоток» будет происхо-
дить существенно быстрее, чем распознавание слова «дробилка».
44
3. Экземпляры. Если попросить интервьюируемого назвать несколь-
ко экземпляров некоторого понятия, то прототипы будут назы-
ваться чаще.
Наверняка читатель играл в такую игру. Загадывающий предвари-
тельно записывает на бумаге три слова, а затем просит партнера начать
обратный отсчет от ста. Дождавшись момента, когда партнер отвлечет-
ся на счет, загадывающий просит:
1. Назвать любого поэта.
2. Назвать любой плод.
3. Назвать любой инструмент.
После того, как партнер делает это, загадывающий торжествующе по-
казывает записанные им предварительно на бумаге ответы: «Пушкин»,
«яблоко» и «молоток». Очевидно, что на самом деле таким образом
выделяются прототипы соответствующих понятий.
В отличии от аристотелевского подхода, в котором все экземпляры
класса представляются равноценными, в теории прототипа имеется ме-
ра соответствия экземпляра классу. Очевидно, что наиболее близкими
к классу экземплярами являются прототипы. Эти экземпляры распола-
гаются «в центре» понятия. Другие экземпляры располагаются «чуть
дальше». Понятие может иметь несколько почти равноценных прототи-
пов. Например, в качестве прототипа понятия «поэт» может выступать
также и экземпляр «Лермонтов», а для представления понятия «плод»
можно использовать и «абрикос». Меру принадлежности экземпляра
данному классу можно оценить сходством с данного экземпляра с про-
тотипом класса понятия. Оказывается, как мы увидим чуть позже, мера
соответствия экземпляра классу этого экземпляра является метрикой ,
т.е. удовлетворяет всем формальным свойствам, предъявляемым к ма-
тематическому определению функции метрики.
Другим новым подходом, связанным с теорией прототипа и также
предложенным Рош [67], является метод, основанный на так называ-
емых понятиях базового уровня . Такие понятия задаются в иерархии
типов и обычно связаны с какими-нибудь моторными или сенсорными
действиями. Например, на вопрос «На чем Вы сидите?» обычно от-
вечают: «на стуле», а не «на офисном кресле», «кухонном стуле» или
просто «на мебели». Стул, как понятие, связан с его основной моторной
функцией— сгибанием ног в коленях. Кроме того, стул— это наиболее
высокое по уровню понятие, которое можно нарисовать. Для следую-
щего по уровню понятия «мебель» этого сделать уже невозможно. Для
45
традиции, которая основана на аристотелевском понимании типа как
совокупности пар атрибут-значение, выделить на этом основании поня-
тия базового уровня затруднительно. Функционально, можно сказать,
что понятия базового уровня представляют собой декомпозицию реаль-
ности на максимально информативные категории. Следовательно, они:
∙ Максимизируют число атрибутов, которые имеют все представи-

тели данного понятия.
∙ Минимизируют число атрибутов, которые имеют все представи-

тели других понятий.
Теорию прототипа можно представить и формально следующим об-

разом. Для каждого понятия 𝑐 выделяется его прототип 𝑝 и задается
специальная функция 𝑑(𝑥, 𝑦, 𝑐)— семантическое расстояние объекта 𝑥
от объекта 𝑦 , если рассматривать их как представителей типа 𝑐. Тогда
объект 𝑥 можно классифицировать следующей рекурсивной процеду-
рой:
1. Предположим, что объект 𝑥 уже был распознан как экземпляр

типа 𝑐, который имеет подтипы 𝑠1 , 𝑠2 , . . . , 𝑠𝑛 .
2. Для каждого подтипа 𝑠𝑖 измеряем семантическое расстояние

𝑑(𝑥, 𝑝𝑖 , 𝑐), где 𝑝𝑖 — представитель подтипа 𝑠𝑖 .
3. Если среди всех таких семантических расстояний 𝑑(𝑥, 𝑝𝑖 , 𝑐) имеет-

ся величина, которая строго меньше всех остальных (уникальный
минимум), то полагаем 𝑐 = 𝑠𝑖 и начинаем заново.
4. Если всех таких семантических расстояний 𝑑(𝑥, 𝑝𝑖 , 𝑐) не имеет-

ся величины, которая строго меньше всех остальных, то процесс
классификации останавливается и считается, что объект 𝑥 имеет
тип 𝑐.
Например, рассмотрим два объекта: «черная кошка» и «рыжая кош-

ка». В классе «Животные» эти два объекта очень похожи и почти не
различаются, но в классе «Кошки» различие между этими объектами
уже более значимо, т.к. объекты имеют все признаки, характерные для
кошек. С другой стороны, если рассматривать тип «Черный объект»,
то в нем объект «черная кошка» будет больше походить на объект «во-
рона» или на объект «кусок угля», нежели на объект «рыжая кошка».
Ввиду того, что описанный способ различения понятий основан на кон-
кретных примерах, функцию семантического расстояния можно также
46
определить исходя из таких примеров. По этой причине, такое определе-
ние типов особенно популярно в различных, основанных на статистике
приложениях, таких как кластерный анализ и нейронные сети.
В 2000 году была издана книга «Понятийные пространства» [48]
профессора университета Лунд (Швеция) Питера Гарденфорса. В этой
книге, Гарденфорс предложил использовать геометрический подход к
представлению понятий. В этом подходе, свойства понятий представ-
ляются в виде размерностей понятийного пространства, получаемого
декартовым произведением свойств и снабженным определенной метри-
кой. Каждое понятие представляет собой выпуклую область простран-
ства. Конкретные экземпляры понятия представляются в виде точек
данной области. Между экземплярами определено расстояние, кото-
рое в предыдущем параграфе мы назвали «семантическим». Некоторые
свойства взаимосвязаны друг с другом, т.е. в человеческом сознании
неотделимы друг от друга. Например, такие свойства цвета, как цвет-
ность, яркость и насыщенность, являются неотделимыми. Гарденфорс
объединяет такие свойства в собственные пространства, называемые до-
менами (domains). Объединение свойств в домены чрезвычайно важно
для правильного моделирования человеческого мышления, т.к. разделе-
ние свойств, которые являются в человеческом сознании неотделимыми
друг от друга приводит к некорректным моделям. Гарденфорс выделя-
ет три уровня представления процесса человеческого мышления:
1. Базовый уровень, на котором рассматриваются биологические ме-

ханизмы, обеспечивающие возможность мышления. Эти механиз-
мы обычно моделируются посредством так называемых «нейрон-
ных сетей».
2. Геометрический уровень, на котором мышление представляется

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

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

зуется для своих целей. Для объяснения этих связей, Гарденфорс ис-
пользует метафору «джунглей». Предположим, что путник оказывает-
47
ся в джунглях, при этом ему неизвестен дальнейший путь. Он расспра-
шивает аборигена и тот ему объясняет дальнейший путь следующим
образом: «пройдешь триста шагов прямо, потом свернешь направо и
пройдешь еще двести шагов, после чего поворачивай налево и иди до
тех пор, пока не попадешь на шоссе». В данной ситуации это объяснение
является наилучшим способом донести информацию о пути к шоссе и
это представление пути соответствует базовому уровню. Но предполо-
жим, что путь до шоссе слишком длинный и требует многих поворотов,
запоминания количеств шагов и т.п. вещей. В этом случае, подобное
объяснение не годится, т.к. просто запутает путника еще больше. Необ-
ходимо дать путнику значимые ориентиры. Иначе говоря, хорошее опи-
сание пути до шоссе в этом случае выглядело бы примерно так: «иди
прямо, пока не встретишь баобаб с дуплом чуть ниже моего роста, за-
тем поверни направо и иди до берега реки, а по нему иди влево до тех
пор, пока не встретишь грунтовую дорогу, вот по ней свернешь направо
и дойдешь до шоссе». Это представление пути соответствует геометри-
ческому уровню, здесь уже встречаются понятия (баобаб, река, дорога),
но они взаимосвязаны между собой, привязаны к джунглям естествен-
ным образом (нахождением в них). Если бы у путника была карта, то
единственное, что было бы ему необходимо от аборигена, это указание
на карте места, где в данный момент путник находится, и направление
сторон света. Этого было бы достаточно, чтобы путник сам отыскал
дорогу к шоссе. Карта соответствует символьную уровню представле-
ния. На карте местность четко размечена в соответствии с масштабом
карты, выделены примечательные для данной местности области, этим
областям даны имена и т.д.
Конечно, можно задать законный вопрос: зачем использовать но-
вые теории представления понятий, если уже имеется аристотелев-
ская? Определение типов с помощью атрибутов согласно аристотелев-
ской традиции вполне нормально работает, поэтому не ясно, есть ли
еще какой-нибудь интерес, кроме академического, в новой теории зада-
ния понятий? Во-первых, новые теории позволяют точнее определить
некоторые аспекты человеческого мышления, которые не покрываются
аристотелевской теорией. В этом смысле, аристотелевская теория пред-
ставления понятий относится к новым теориям понятий точно также,
как теория тяготения Ньютона относится к общей теории относитель-
ности. Кроме того, не каждое понятие можно определить посредством
задания его свойств. Приведем пример Витгенштейна из его знамени-
тых «Философских исследований» [2, раздел 66]:
Рассмотрим, например, процессы, которые мы называем
48
«играми». Я имею в виду игры на доске, игры в карты, с
мячом, борьбу и т.д. Что общего у них всех? Не говори «В
них должно быть что-то общее, иначе их не называли бы иг-
рами», но присмотрись, нет ли чего-нибудь общего для них
всех. Ведь, глядя на них, ты не видишь чего-то общего, при-
сущего им всем, но замечаешь подобия, родство, и притом
целый ряд таких общих черт. Как уже говорилось: не ду-
май, а смотри! Присмотрись, например, к играм на доске с
многообразным их родством. Затем перейди к играм в кар-
ты: ты находишь здесь много соответствий с первой группой
игр. Но многие общие черты исчезают, а другие появляются.
Если теперь мы перейдем к играм в мяч, то много общего
сохранится, но многое и исчезнет. Все ли они «развлекатель-
ны»? Сравни шахматы с игрой в крестики и нолики. Во всех
ли играх есть выигрыш и проигрыш, всегда ли присутству-
ет элемент соревновательности между игроками? Подумай о
пасьянсах. В играх с мячом есть победа и поражение. Но в
игре ребенка, бросающего мяч в стену и ловящего его, этот
признак отсутствует. Посмотри, какую роль играет искус-
ство и везение. И как различны искусность в шахматах и в
теннисе. А подумай о хороводах! Здесь, конечно, есть эле-
мент развлекательности, но как много других характерных
черт исчезает. И так мы могли бы перебрать многие, мно-
гие виды игр, наблюдая, как появляется и исчезает сходство
между ними.
Таким образом, для понятия «игра» чрезвычайно трудно, если вооб-
ще возможно, выделить разделяемый всеми объектами, которым мы
даем наименование «игра», набор свойств. С другой стороны, простое
перечисление нескольких прототипов этого понятия позволяет вполне
определенно передать смысл понятия «игра» другому человеку. Вот
что по этому поводу говорит Витгенштейн [2, раздел 69]:
Как же тогда объяснить кому-нибудь, что такое игра? Я по-
лагаю, что следует описать ему игры, добавив к этому: «Вот
это и подобное ему называют играми». А знаем ли мы са-
ми больше этого? Разве мы только другим людям не можем
точно сказать, что такое игра? Но это не неведение. Мы не
знаем границ понятия игры, потому что они не установлены.
Как уже говорилось, мы могли бы для каких-то специальных
целей провести некую границу. Значило бы это, что только
теперь можно пользоваться данным понятием? Совсем нет!
49
Разве что для данной особой цели. В такой же степени, в ка-
кой дефиниция «1 шаг = 75 см», вводила бы в употребление
меру длины «1 шаг». Если же ты попытаешься мне возра-
зить: «Но ведь раньше это не было точной мерой длины», я
отвечу: ну и что, значит, она была неточной. Хотя ты еще
задолжал мне определение точности.
Концептуальный релятивизм обычно не использует термин «онто-

логия» для обозначения особого представления бытия членами данной
социальной группы. Для этого используется термин «концептуальная
схема».5 В концептуальном релятивизме под концептуальной схемой по-
нимается способ организации опыта, основанный на системе специфи-
ческих категорий, придающих форму чувственным данным. Концеп-
туальная схема выражает точки зрения индивидов, культур и эпох на
происходящие события [3]. В нашей интерпретации концептуального
релятивизма за каждой концептуальной схемой стоит некоторая цель,
определяющая точку зрения на бытие, также называемую контекстом
рассмотрения. В конкретном контексте рассмотрения принимаются во
внимание только некоторые, относящиеся к цели данной задачи, аспек-
ты вещей, т.е. происходит типизация вещей и объединение их в классы
на основе этой типизации. Между типами вещей определяются соотно-
шения. Тогда, концептуальная схема и будет представлять собой сово-
купность таких типов и соотношений между ними. При этом не фик-
сируется, каким образом производится типизация, на основе аристоте-
левской традиции атрибутов или еще как-то иначе. Главным является
наличие особой концептуальной схемы задачи, определяющейся целью
этой задачи и выражаемой в терминах типов и соотношений между
ними. Также, специфической особенностью данной трактовки термина
«концептуальная схема» является то, что рассматриваются концепту-
альные схемы конкретных задач, для которых ясно определены их цели
и, следовательно, вытекающие из них контексты рассмотрения бытия.
С другой стороны, понятие, обозначаемое термином «задача», можно
трактовать гораздо шире, нежели обозначение конкретной инженерной
задачи. Задача может быть весьма сложной и, таким образом, вклю-
чать в себя большой набор подзадач. В этом случае, задача превращает
в парадигму . Цели парадигмы также сложны и составляют ее концеп-
5 Термин «концептуальная схема» весьма многозначен, особенно в компьютерной
науке, где он используется в базах данных. Автор особо подчеркивает, что приве-
денная здесь трактовка этого термина унаследована из философии концептуально-
го релятивизма (в которой этот термин является основополагающим), и ее следует
рассматривать именно в этом контексте.
50
цию. Полезность формального описания онтологий как раз и основана
на том факте, что такие описания созданы в рамках одной парадигмы
и, таким образом, описываемые онтологии имеют за собой общие це-
ли, в свете которых возможно их совместное использование. Приведем
формальное определение концептуальной схемы задачи, заимствован-
ное нами из философии концептуального релятивизма [3].
Определение 2.1 Концептуальная схема задачи— это способ орга-

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

гий. Такие библиотеки, как правило, организуются на основе иерархи-
ческой зависимости, когда понятия, описываемые в одной онтологии,
определяются на основе понятий, описанных в другой. На вершине
этой иерархии находятся так называемые онтологии верхнего уровня
(top-level ontology). В силу своей специфики, онтологии верхнего уров-
ня должны содержать понятия высокого уровня абстракции, достаточ-
но общие для того, чтобы на их основе затем можно было производить
концептуализацию предметных областей различных задач. Выше мы
говорили, что за каждой концептуальной схемой стоит определенная
цель, которая обуславливает ее содержание. Цель, определяющая со-
держание концептуальных схем онтологий верхнего уровня, сходна с
той, что традиционно ставилась философами при онтологическом опи-
сании мира— это ответ на вопрос: что такое бытие? На этот вопрос, как
показала история, философы отвечали по разному, поэтому нет ничего
удивительного в том, что и сегодняшние их последователи создают вер-
сии онтологий верхнего уровня, которые отличаются от других. Каж-
дая из приведенных ниже версий описания бытия имеет свои преимуще-
ства и недостатки, и наверное, не существуетсамой правильной версии ,
но различные варианты описаний дополняют друг друга и позволяют
получить более полный взгляд на бытие. Следует также отметить, что
все описываемые онтологические конструкции созданы в рамках еди-
ной концептуальной схемы, которую можно назвать культурной мат-
рицей европейской цивилизации . Другие культуры, как показала исто-
рия, могут быть основаны на ином онтологическом содержании. Онто-
логические взгляды европейских философов унаследованы в основном
51
от древнегреческих авторов, последователей аристотелевской онтоло-
гической традиции [см. 58]. Как увидит читатель, приведенные ниже
различные версии онтологий верхнего уровня в основном выдержаны
в рамках этого подхода. На основе лингвистического анализа древне-
греческого языка, Аристотель выделяет десять основных категорий ве-
щей. Ключевой категорией в онтологии Аристотеля является категория
субстанции , как первичной основы всех других вещей. Категории ко-
личества и качества существуют тогда и только тогда, когда их субстан-
ции имеют эти количества и качества, а категории отношения между ве-
щами существуют только тогда, когда субстанции этих вещей связаны
между собой этими отношениями. Все другие категории вещей в этом
смысле зависимы от субстанций. С этой точки зрения, Аристотель раз-
деляет Реальность на независимые сущности (субстанции) и зависимые
(все остальные вещи). Другим таким разделением в Аристотелевской
онтологии является разделение на возникающие (occurrent) инепре-
рывные (continuant) объекты. Непрерывные объекты существуют как
единое целое во все моменты времени своего существования, возникаю-
щим же объектам, напротив, необходимы промежутки времени, чтобы
собрать себя в единое целое. Например, категории субстанции, количе-
ства, качества и пространства могут рассматриваться как непрерывные
сущности, так как не нуждаются в своем определении временных про-
межутков. Категории действия, страсти (волнения) и самого времени
являются примерами возникающих объектов. Аристотель также вводит
понятие универсалии . Универсалия Аристотеля— это синоним того, что
мы называем понятием или типом. Читатель убедится, что онтологии
в приведенном далее списке представляют собой различные вариации
приведенного выше описания онтологии Аристотеля.
Список онтологий ниже не претендует на полноту, цель его приве-
дения состоит в том, чтобы, с одной стороны, дать читателю представ-
ление о принципах, на которых строятся онтологии верхнего уровня,
и с другой стороны, познакомить читателя с наиболее популярными
на сегодня базами онтологий. Читатель, несомненно, отметит сходство
онтологий верхнего уровня с философскими онтологиями, т.е. теми, ко-
торые строятся философами для объяснения метафизики Мира.
«Бриллиант» Джона Совы

В своей книге «Представление знаний» [70] американский специалист
по искусственному интеллекту Джон Сова представил свою версию он-
тологии верхнего уровня в виде упорядоченной структуры специально-
го вида (решетки). Эта решетка понятий верхнего уровня получила на-
52
звание «бриллиант Совы». Бриллиант Совы имеет два представления:
в виде решетки и в виде таблицы, представленные, соответственно, на
рисунках 2.1 и 2.2.
⊤
Íåçàâèñèìûé Ñâÿçàííûé Ïðîìåæóòî÷íûé

Ôèçè÷åñêèé Àáñòðàêòíûé
Àêòóàëüíîñòü Ôîðìà Çàõâàò Ïðåäëîæåíèå Ñâÿçü Âûâîä

Ïðîäîëæèòåëüíûé Âîçíèêàþùèé
Îáúåêò Ïðîöåññ Ñõåìà Ñêðèïò Ñðàùèâàíèå Ó÷àñòèå Îïèñàíèå Èñòîðèÿ Ñòðóêòóðà Ñèòóàöèÿ Ïðè÷èíà Öåëü
Рис. 2.1: «Бриллиант» Джона Совы
Физический Абстрактный
Продолж Возник Продолж Возник
Независимый Объект Процесс Схема Скрипт
Связанный Захват Участие Описание История
Промежуточный Структура Ситуация Причина Цель
Рис. 2.2: «Бриллиант» Джона Совы в табличном представлении
Джон Сова построил свою версию онтологии верхнего уровня осно-
вываясь, в основном, на философских работах Чарльза Пирса и Аль-
фреда Уайтхеда. Как уже отмечалось выше, понятия «бриллианта»
упорядочены и этот порядок имеет структуру полной решетки6 . Отно-
шение порядка в решетке Совы— это известное в классификации отно-
шение вида тип-подтип. Полнота решетки обусловливает наличие двух
6 Для любого подмножества элементов частично-упорядоченного множества
нижней (верхней) гранью этого подмножества называется любой элемент, кото-
рый меньше (больше) любого элемента подмножества. Таких элементов может быть
много. Точной нижней (верхней) гранью подмножества называют наибольший (наи-
меньший) элемент из всех нижних (верхних) граней данного подмножества. Решет-
кой называют частично-упорядоченное множество, в котором каждое подмножество
имеет точную верхнюю и нижнюю грани. Примером решетки может служить си-
стема подмножеств некоторого множества. Между подмножествами можно ввести
отношение частичного порядка: 𝐴 ≤ 𝐵 если 𝐴 ⊆ 𝐵 . Тогда, для любого семей-
53
специальных элементов, наверху и внизу порядковой структуры. Эле-
мент «⊤» можно представлять себе как синоним термина «сущность»,
любой элемент решетки Совы является сущностью и потому подтипом
этого элемента. ⊤ также можно рассматривать как наиболее абстракт-
ный объект, который трактуется как неделимое целое. Элемент внизу
решетки Совы обозначается через «⊥» и представляет собой «невоз-
можную сущность»— абсурдное понятие, которое не имеет смысла. На-
ходящиеся между этими элементами понятия имеют реальное содержа-
ние. Онтология Совы включает в себя двенадцать категорий, которые
характеризуются различными аспектами. На верхнем уровне находятся
три характеризующих явления аспекта.
∙ Первый аспект говорит о том, принадлежит ли данный элемент

рассмотрения реальному миру вещей или представляет собой аб-
страктное понятие, которое не обозначает никакого реального
предмета— это разделение элементов предметной области на фи-
зические(physical) и абстрактные
(abstract).
∙ Второй аспект касается взаимосвязанности элементов друг с дру-

гом. Если элемент определяется сам по себе, не требуя в опреде-
лении связи с какими-либо другими элементами, то он трактует-
ся как независимый (independent). Если элемент определяется в
связи с каким-либо другим элементом предметной области, то он
трактуется как относительный (relative). Наконец, если элемент
определяется, как связующее звено между двумя другими эле-
ментами, то он определяется как промежуточный (mediating).
Каждую из характеристик данного аспекта можно, в свою оче-
редь, разделить на две категории. Независимые элементы можно
охарактеризовать на основе актуальности и формы. Актуальность
характеризует отношение к реальности, т.е. то, является ли дан-
ный элемент предметной области объектом или процессом. Форма
говорит о том, как описывается данный элемент, статически через
некую схему(schema), или динамически посредством некоторого
ства подмножества существуют точная нижняя и верхняя грани, определяемые как
пересечение и объединение элементов этого семейства, соответственно. Семейство
подмножеств также представляет собой полную решетку, т.е. решетку, в которой
имеются максимальный и минимальный элементы. Максимальный элементы срав-
ним с каждым элементом решетки и больше него, а минимальный, соответственно,
меньше. В решетке подмножеств некоторого множества максимальным элементом
является само это множество, а минимальным— пустое множество. Решетка пред-
ставляет собой алгебраическую структуру, где в качестве операций над элементами
выступают операции нахождения их точных нижних и верхних граней.
54
скрипта (script). Связанные элементы можно охарактеризовать
посредством способа связывания: либо элемент непосредственно
выражает некий захват (prehension) одним элементом другого
(тогда захватывать можно либо сращиванием (juncture), либоуча-
стием (participation)), либо элемент каким-то образом выража-
ется через другой в виде некоторого предложения (proposition).
В последнем случае это предложение может иметь вид некото-
рого описания (description) или некоторой истории (описания во
времени— history). И, наконец, если элемент характеризуется как
промежуточный, то он может быть либо связью (nexus) между
физическими элементами, либо выводом(intention) какого-то аб-
страктного элемента из другого.
∙ Третий аспект описывает, каким образом данный элемент суще-
ствует во времени. Если элемент существует какой-то, достаточ-
но продолжительный и устойчивый промежуток времени, то этот
элемент можно назвать продолжительным
(continuant). В про-
тивном случае назовем его возникающим
(occurrent).
Каждый элемент предметной области может принадлежать в точности
одной из следующих двенадцати категорий (описания категорий взяты
из [70]):
∙ Объект (Object). Сущность, которая может существовать
некий стабильный периоде времени. Объектом может быть
обычный физический предмет, а также экземпляр класса в
объектно-ориентированном языке программирования.
∙ Процесс (Process). В зависимости от масштаба времени рассмот-
рения, одни и те же сущности могут рассматриваться как объекты
и как процессы. Например, алмаз обычно понимается как объект,
но если взять достаточно продолжительный промежуток времени,
например, несколько миллионов лет, то алмаз можно рассматри-
вать как процесс изменения его атомарной структуры. Процес-
сы всегда имеют начальную и конечную точки, между которыми
происходят изменения. Процессы делятся на дискретные непре-
и
рывные .
∙ Схема (Schema). Схема представляет собой абстрактную форму,
чья структура не содержит связей, связанных со временем. В ка-
честве примеров структур можно привести геометрические фор-
мы, синтаксические структуры предложений некоторого языка
или содержимое цифровой фотографии.
55
∙ Скрипт (Script). Скрипт— это абстрактная форма, которая
представляет собой временную последовательность. Примерами
скрипта являются компьютерная программа, рецепт выпечки тор-
та или партитура музыкального произведения.
∙ Сращивание (Juncture). Сращивание можно охарактеризовать как

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

времени, в котором заинтересован участвующий. Элемент, кото-
рый участвует, называется участником, а участие производится
в некотором процессе.
∙ Описание (Description). Описание— это предложение

, в котором
рассказывается о том, каким образом данная схема
характеризует
некоторые аспектыпродолжительной сущности.
∙ История (History). История— это предложение, которое связыва-

ет некий скрипт с периодами некоторой возникающей сущности.
Например, компьютерная программа— это скрипт, сам компью-
тер, исполняющий данную программу,— это процесс (возникаю-
щая сущность), а информация, закодированная в последователь-
ности инструкций программы,— это история.
∙ Структура (Structure). Структура связывает несколько элемен-

тов и связи между этими элементами составляют структуру. Та-
ким образом, структура— это связь некоторой продолжительной
сущности.
∙ Ситуация (Situation). Ситуация связывает участников некоторо-

го процесса, в различные периоды которого могут вовлекаться
различные участники. Таким образом, ситуация— это связь неко-
торой возникающей сущности.
∙ Причина (Reason). В отличии от простого описания, причина со-

держит объяснение, представленное в виде вывода. Например,
для празднования дня рождения, описание может представлять
список подарков, но причина представляет собой описание того,
каким образом этот список связан с данным празднованием.
56
∙ Цель (Purpose). Цель объясняет причину существования процес-
са. Например, текст и ноты песни «С днем рождения тебя» состав-
ляют скрипт, описание того, как люди пели эту песню на празд-
новании дня рождения, составляет историю, а объяснение данной
ситуации— это цель.
Cyc
Cyc [12] (образовано от «encyclopedia» и читается как «Цик») пред-
ставляет собой проект по созданию базы знаний большого объема, ко-
торая призвана моделировать повседневное человеческое мышление и,
тем самым, чтобы помочь авторам решать сложные задачи из обла-
сти искусственного интеллекта в различных областях знаний. Автором
проекта Cyc является Дуглас Ленат— американский исследователь в
области ИИ. База знаний Cyc начала наполняться в 1984 году и попол-
няется до сих пор. В настоящий момент база Cyc содержит порядка 2,2
миллиона утверждений. Изначально, База знаний проекта Cyc не пред-
назначалась для открытого использования, поэтому прямого доступа к
накопленному запасу знаний у непривилегированных пользователей не
имеется. Однако, существует открытый фрагмент базы знаний Cyc—
так называемый OpenCyc [39]. Хороший обзор проекта Cyc приведен в
статье М. Алексеевой [1]. Знания в базе Cyc записываются на специаль-
ном языке— CycL в форме утверждений вида «Всякое дерево является
растением» или «Растения смертны». Синтаксис языка CycL схож с
LISP, утверждения также формируются в виде списков. В системе Cyc
также имеется машина логического вывода, которая может отвечать на
вопросы, опираясь на утверждения, имеющиеся в базе знаний. В базе
знаний Cyc можно выделить факты, которые задают общие высоко-
уровневые понятия. Эти факты представляют собой онтологию верх-
него уровня. Мы рассмотрим систему проекта Cyc подробно в главе
5. Поэтому, здесь подробно описывать содержание онтологии верхнего
уровня проекта Cyc не будем.
Basic Formal Ontology (BFO)

Проект BFO [23] разработан под руководством известного американ-
ского исследователя в области онтологического моделирования Барри
Смита [11]. В отличии от Cyc, проект BFO изначально создавался как
онтология верхнего уровня, предназначенная для использования в раз-
личных научных проектах. В частности, BFO используется в проек-
те OBO Foundry (Открытая Медицинская Онтология [см. 22]). Онто-
57
логии BFO разделены на два типа, соответствующих различным спо-
собам существования бытия во времени или двум основным способам
пространственно-временного взаимодействия [51].
1. Первый тип содержит в себе понятия времени, т.е. в таких онто-

логиях предполагается, что время уже определено каким-то обра-
зом и не берется в расчет в данной онтологии. Можно сказать, что
рассматриваются только трехмерные (3D) объекты, в отличии от
четырехмерных объектов (3D + Время) в онтологиях второго ти-
па. Онтологии первого типа подобны фотографических снимкам,
которые запечатлевают какой-то момент реальности и реальность
можно представить как последовательность таких фотоснимков.
Онтологии данного типа имеют название SNAP— онтологий (от
английского snapshot— снимок).
2. Второй тип рассматривает объекты во времени, т.е. в четырех-

мерном континууме вида пространство-время. с точки зрения ин-
женерии такая онтология покрывает время (spans time), поэтому
онтологии этого типа носят название SPAN— онтологий.
Таким образом, BFO позволяет описывать предметную область с двух

основных точек зрения: пространственной, описывающей форму и ста-
тическую схемы объекта рассмотрения, и временной, отражающей ди-
намические характеристики предметной области. Описания дополняют
друг друга и вместе дают более полную картину бытия. SNAP— онто-
логии описывают объекты, устойчивые от изменений на какой-то доста-
точно продолжительно для рассмотрения промежутке времени, SPAN—
онтологии описывают процессы. Таким образом, все объекты рассмот-
рения можно разделить на постоянные изменяющиеся
и . Постоянный
объект характеризуется размерностью, а также может быть независи-
мой или зависимой сущностью. Изменяющийся объект также характе-
ризуется размерностью, временной координатой, имеет динамическую
характеристику (это может быть процесс, составная часть процесса или
совокупность процессов), а также характеризуется отношением к своим
пространственным компонентам: описывает стационарные или переме-
щающиеся в пространстве объекты. Онтология BFO реализована на
языках:
∙ OWL— языке, основанном на дескриптивной логике и созданном

для описания семантики Web. Об этом языке мы поговорим ниже
подробно.
58
∙ Isabelle [62]— языке логики первого порядка, созданном американ-
ским онтологом Томасом Битнером [7].
DOLCE
DOLCE [24] (Descriptive Ontology for Linguistic and Cognitive
Engineering— Описательная Онтология для Лингвистической и Когни-
тивной Инженерии) представляет собой первый из разработанных мо-
дулей так называемой WonderWeb Foundational Ontologies Library—
библиотеки онтологий верхнего уровня под названием «WonderWeb».
Основным предназначением онтологий этой библиотеки является под-
держка взаимодействия различных агентов, которые чаще всего пред-
ставляют собой компьютерные программы, разработанные для целей
ИИ. Более конкретно, онтологии библиотеки проекта WonderWeb раз-
рабатываются для следующих целей [61]:
∙ Быть отправной точкой для разработки новых онтологий. Одной

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

онтологий.
∙ Быть основанием для интеграции существующих онтологий.
WonderWeb разрабатывается в Лаборатории Прикладной Онтологии

(LOA— Laboratory for Applied Ontology [16]) под руководством извест-
ного итальянского специалиста Николо Гуарино [6]. DOLCE представ-
ляет один из модулей библиотеки проекта WonderWeb, разработанный
для того, чтобы формализовать понятия, лежащие в основании онтоло-
гии естественного языка и его когнитивных смыслов. Авторы DOLCE
предлагают, например, использовать эту онтологию для того, чтобы
сделать более ясным содержимое лингвистической онтологии WordNet.
Итак, онтология DOLCE имеет ясную прагматическую цель, обуслав-
ливающую ее содержание— это не коллекция общих онтологических ка-
тегорий реальности, как в описанных выше «бриллианте» Совы или
проекте BFO, но онтология, созданная для лингвистов и специалистов
по когнитивной науке. Авторы проекта используют термин «cognitive
59
bias» для обозначения того факта, что содержимое онтологии DOLCE
имеет когнитивный и лингвистический контексты. Если в «бриллиан-
те» Совы описываются исключительно общие абстрактные категории,
то в противоположность этому, онтология DOLCE представляет собой
коллекцию частностей . Под частностями здесь подразумевается по-
нятия, которые, в отличии от общих понятий (универсалий), не имеют
экземпляров. Онтология DOLCE основана на так называемом мульти-
пликативном подходе ,— это, в данном случае означает, что некоторые
сущности онтологии могут быть расположены в одной и той же про-
странственно-временной точке. Например, в чем состоит разница меж-
ду понятиями «ваза» и «кусок глины»? Предполагается, что главное
различие состоит в том, что для понятия «ваза» ее форма и топологи-
ческие свойства неизменяемы, что неверно для понятия «кусок глины».
Следовательно, мы можем называть данный предмет и вазой и куском
глины, не отождествляя эти понятия, но полагая, что ваза состоит
из
куска глины.
Все сущности онтологии DOLCE разделяются согласно следующим
четырем характеристикам (тетрахотомия, разделяющаяся на две дихо-
томии: устойчивый и неустойчивый, и качества и регионы):
∙ Устойчивые (Endurant) сущности. Устойчивый означает то же,

что и продолжительный в бриллианте Совы. Устойчивые сущно-
сти полностью присутствуют во все моменты времени, в которые
они существуют.
∙ Неустойчивые (Perdurant) сущности. неустойчивые сущности

представляют собой объекты, которые возникают в контексте их
рассмотрения, а также могу изменяться их составные части. В
терминологии BFO это означает, что снимки неустойчивых объ-
ектов, сделанные в разные моменты времени, могут друг от друга
отличаться, но для устойчивых объектов это не так (SNAP и SPAN
сущности).
∙ Качества. Качества можно рассматривать как базовые свойства,

которые могут быть восприняты или измерены. К качествам мож-
но отнести: цвета, размеры, звуки, запахи, веса, длины, электриче-
ские заряды и т.д. Качество можно мыслить как синоним термина
«свойство», однако свойство относится к категориям-универсали-
ям, тогда как качество— это частность. Качества имеют типы, т.е.
запахи— это тип качеств запахов, веса— это тип качеств весов и
т.д.
60
∙ Регионы. Регионы— этот непрерывные подобласти понятийного
пространства Гарденфорса [48]. Все качестве как сущности онто-
логии DOLCE различны и индивидуальны, но могут ссылаться на
одни и те же точки понятийного пространства данной онтологии.
Дальнейшую таксономию онтологии DOLCE мы здесь описывать не

будем, ввиду недостатка места и чтобы не откланяться от основного
изложения.
Онтология DOLCE реализована на языке OWL и может быть сво-
бодно загружена с сайта Лаборатории Прикладной Онтологии [24].
General Formal Ontology (GFO)

GFO [18] изначально создавалась как онтология верхнего уровня, на
основе которой можно было бы производить концептуальное модели-
рование для различных целей. Онтология GFO разрабатывалась под
руководством известного немецкого специалиста по онтологическому
моделированию Гейнриха Герре [5] членами исследовательской груп-
пы Onto-Med [14]. В отличии от, например, онтологии DOLCE, кото-
рая имеет ярко выраженный лингвистический и когнитивный контекст,
GFO создавалась для описания Реальности в соответствии с философ-
скими теориями последнего времени. Элементы онтологии представля-
ют собой классы, множества и атомы. Классы и множества различа-
ются в обычном теоретико-множественном смысле, т.е. мир делится на
типы, где атомы и множества— это элементы типа 0 и также присут-
ствует класс 𝐶[0] всех элементов типа 0. На основе уже имеющихся
классов можно построить новый класс «всех элементов данных клас-
сов». Такое разделение позволяет избежать трудностей, связанных с
парадоксом Рассела. Также присутствует специальный класс формаль-
ных отношений . Атомы могут быть, либо индивидами, либо универса-
лиями, либо пространственно-временными сущностями. Индивид, это
единичная сущность, которая существует в пространстве и во време-
ни. Универсалии имеют экземпляры. Предполагается, что индивиды
представляют собой экземпляры универсалий, т.е. существуют в инди-
видах, но не могут существовать без них. Это положение, очевидно, в
точности выдерживает Аристотелевский подход к понятию универса-
лии. Универсалии также можно понимать как основные единицы мыш-
ления. Пространственно-временные свойства атомов выражаются по-
средством категорий хроноида топоида
и . Хроноиды понимаются, как
связанные временные интервалы, в топоиды,— как пространственные
регионы, имеющие мереотопологическую структуру (т.е. определенным
61
образом составляемые из своих частей). Как уже говорилось выше, ин-
дивиды— это атомы, внедренные в пространство и время. Такое внед-
рение характеризуется разбиением индивидов на объекты процессы
и .
Это различие мы уже обсуждали выше (SNAP и SPAN сущности в он-
тологии BFO, а также устойчивые и неустойчивые элементы онтологии
DOLCE). В GFO используется также понятие субстанции , под которой
понимается объект, имеющий свойства и обладающей протяженностью
в пространстве. Другой сорт объектов— это моменты , сущности, кото-
рые могут существовать только как части других объектов (например,
электрическое напряжение существует только в некотором проводни-
временные
ке). Все процессы характеризуются понятием и разделяют,
процессы перемещения изменения истории состоя-
собственно, на , , , ,
ния границы процессов
и . Субстанции вместе со своими моментами об-
разуютконфигурации . Составная конфигурация, рассматриваемая как
ситуацией
единое целое, называется . Понятие ситуации основано на
работах Джона Барвиза и Джона Перри [41; 42], посвященных опи-
санию математической теории ситуаций . Определение ситуации, ис-
пользуемое в онтологии GFO, отличается от используемого в теории
ситуаций, но в общих чертах сходно с последним. В GFO используется
двойственное определение понятия ситуации: статическое ( ситуация)и
динамическое ( ситуоид ). Ситуоид— это часть мира, рассматриваемая
как целое, но вместе с полной историей всех онтологических сущно-
стей, которые эту часть составляют. Таким образом, каждый ситуоид
имеет продолжительность во времени и заключен в некоторый топоид,
представляющий его пространственную конфигурацию. Ситуация— это
статический снимок ситуоида в какой-то момент времени, рассматрива-
емый как атомарный. Рассмотрим, например, фразу «Иван целует Ма-
шу». Здесь Иван и Маша связаны между собой отношением «целовать»,
но эта конфигурация еще не образует ситуоид. Для образования ситуо-
ида необходимо рассмотреть окружение, в котором происходит процесс,
описанный этой фразой. Может быть, Иван гуляет с Машей в лесу, а мо-
жет быть они сидят на скамейке на оживленной улице. Полное описание
истории возникновения ситуации, описываемой фразой «Иван целует
Машу», вместе с описанием того, где это происходит, образует ситуоид.
Хороший обзор структуры онтологии GFO дан в работах [59; 46].
IDEAS
IDEAS [13] (International Defence Enterprise Architecture Specification)—
это Международная Оборонная Промышленная Архитектурная Специ-
фикация для обмена данными. Для стандартизации обмена использу-
62
ется онтология, которая также называется IDEAS. Онтология IDEAS
разделяется на онтологию верхнего уровня— IDEAS Foundation, и бо-
лее конкретную IDEAS Model. Онтология IDEAS использует подход,
в котором все сущности онтологии предполагаются расположенными
в 4D континууме, состоящим из трех пространственных измерений и
одного временного. IDEAS Foundation была разработана с использова-
нием так называемого BORO метода [40] разработки онтологий для
промышленности, содержание которого будет рассмотрено ниже в этой
главе.
Онтология IDEAS Foundation имеет достаточно простую структуру
и содержит элементы четырех базовых категорий:
∙ Индивиды — все, что имеет физическую протяженность.

∙ Типы — множества индивидов, типов и кортежей.
∙ Кортежи — отношения между двумя и более индивидами, типами

или кортежами.
∙ Сущности — корневая категория онтологии, может быть индиви-

дом, типом или кортежем.
Примеры индивидов: Вы, я, моя машина, Земля, Останкинская теле-

башня. Примеры типов: желтая вещь, люди, здания, ранги (ранг пред-
ставляет собой тип, чьими элементами являются типы). Примеры кор-
тежей: мой автомобиль и его двигатель (часть-целое), желтые вещи
и ньюйоркские такси (тип-подтип), черные вещи и мой автомобиль
(тип-экземпляр). Ввиду того, что IDEAS Foundation закодирована на
языке RDF, подавляющее большинство отношений в ней— это бинар-
ные отношения. Этот факт отражен в онтологии категорией пара
. Он-
тология IDEAS Foundation имеет три предопределенных отношения:
∙ Часть-целое. Данное отношение связывает между собой двух ин-

дивидов, из которых один является целым, а другой его частью.
Ввиду того, что онтология IDEAS моделирует 4D континуум про-
странства-времени, это отношение может также связывать неко-
торый процесс (временной интервал) с какой-то его фазой выпол-
нения.
∙ Тип-подтип. Связывает некоторый тип с другим типом. Предпо-

лагается, что множество экземпляров подтипа вложено во множе-
ство экземпляров надтипа.
63
∙ Тип-экземпляр. Связывает тип с элементами множества, которое
он представляет.
WordNet
WordNet [25]— это описание английского языка, представленное в ви-
де так называемого семантического словаря , представляющего собой
обычный словарь, дополненный семантическими отношениями между
своими элементами, задаваемыми в виле семантической сети специфи-
ческого вида. Множество слова английского языка факторизовано по
отношению синонимии, класс этой факторизации называется синсет
(synset). Между синсетами и задаются семантические отношения. Цель
разработки WordNet двоякая: с одной стороны, предоставить интуитив-
но понятный словарь английского языка и, с другой стороны, предо-
ставить инструмент, который может быть использован для автомати-
ческой обработки текстов на английском языке и для другой деятельно-
сти в области ИИ. База данных WordNet содержит порядка 150 тысяч
определений слов, сгруппированных в примерно 115 тысяч синсетов, и
в сжатом виде составляет примерно 12 гигабайт. Разработка WordNet
началась в 1985 году в Лаборатории Когнитивных Наук Принстонско-
го университета под руководством профессора философии Джорджа
Миллера [33].
WordNet можно рассматривать как специального вида лексическую
онтологию . Однако, такое представление требует дополнительной ра-
боты. Каждый синсет базы WordNet можно рассматривать как смыс-
ловую единицу, т.е. онтологическую категорию. Между синсетами в
WordNet есть отношение гипонимии, на основе которого можно обра-
зовать таксономию, в которой каждый гипоним представлен как до-
черний элемент своего гиперонима. Однако, для некоторых пар в отно-
шении гипонимии необходимо образовывать не таксономическую пару
(пару отношения тип-подтип), а пару отношения тип-экземпляр. Таким
образом, преобразование базы данных WordNet в онтологию требует
дополнительной работы. Такая работа была проведена, результирую-
щая онтология называется WebKB-2 [20], ее описание можно прочи-
тать в [60]. Итак, WordNet можно рассматривать как онтологию верх-
него уровня, созданную с лингвистическими целями, если включить в
такую онтологию наиболее общие категории, содержащиеся в базе дан-
ных WordNet.
64
Suggested Upper Merged Ontology (SUMO)
SUMO [19]— это онтология верхнего уровня разработанная Рабочей
Группой IEEE по Стандартной Онтологии Верхнего Уровня (IEEE
Standard Upper Ontology Working Group [27]). Цель Рабочей Группой
IEEE состояла в разработке онтологии, пригодной для таких областей
компьютерной инженерии, как обмен данными, информационный по-
иск, автоматический вывод и автоматизированная обработка естествен-
ного языка. Поэтому, SUMO представляет собой объединение несколь-
ких известных онтологий, таких как онтологии, расположенные на сер-
вере Ontolingua, онтология верхнего уровня Джона Совы («бриллиант»
Совы) и многих других. Онтология SUMO разработана на адаптирован-
ной для целей Рабочей Группой IEEE версии языка KIF— SUO-KIF.
Онтология SUMO имеет следующую структуру [35]:
∙ Корнем онтологии является категория сущность (entity).

∙ Сущность может быть, либо абстрактной, либо физической.
∙ Физические сущности— это, либо объекты, либо процессы.
∙ Абстрактная сущность— это количество, атрибут, класс (множе-

ство), отношение, высказывание, граф или элемент графа.
∙ Объект представляет собой то, что обычно люди подразумевают

под этим понятием. Примерами объектов служат обычные физи-
ческие объекты, географические регионы, а также места исполне-
ния (locations) Процессов.
∙ Процесс определяется как нечто, что случается а данном месте

в данное время. Процесс— этодвухобъектный процесс целевой
,
процесс перемещение внутреннее изменение топологическое
, , или
изменение.
∙ Количество— это любая спецификация того, какое число элемен-

тов имеет нечто или насколько оно велико. Соответственно, имеет-
ся два подкласса этой категории: число физическое количество
и .
∙ Атрибут— это качество, которое не рассматривается как подкласс

категории объект.
∙ Класс— это абстрактная сущность, которая может иметь элемен-

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

конченную мысль или множество таких мыслей. Например, фор-
мула (instance Васька Кот) говорит о том, что «Васька»— это эле-
мент множества «Кот».
∙ Граф— это пара взаимосвязанных классов: класса узлов

GraphNodes и класса реберGraphArcs.
∙ Элемент графа— это неделимая часть графа, т.е. либо узел, либо
ребро.
Онтология SUMO довольно объемная, поэтому здесь мы не будем при-

водить все ее категории, полагая, что читателю будет достаточно приве-
денного выше списка для представления о том, что представляет собой
данная онтология. Скажем только, что человек в данной онтологии рас-
сматривается как экземпляр категории когнитивный агент , имеющего
в качестве непрямого предка категорию агент . Интересной особенно-
стью онтологии SUMO является то, что для нее построено полное со-
ответствие с онтологией базы WordNet. Таким образом, SUMO может
быть использована в различных лингвистических разработках, связан-
ных с WordNet, что и делается: существует достаточно большое число
работ по лингвистической тематике [34].
2.3 Методология построения онтологий
В этом разделе мы рассмотрим некоторые популярные методики разра-

ботки онтологий. Автор постарался подобрать примеры таким образом,
чтобы наиболее широко проиллюстрировать различного рода пробле-
мы, с которыми приходится сталкиваться в процессе моделирования.
Мы рассмотрим три следующих методологии:
1. Моделирование программных систем с помощью языка UML.
2. Методология разработки прикладных онтологий Томаса Грубера.
3. BORO метод реорганизации существующих программных систем.
66
Моделирование с помощью UML
В среде программистов большую популярность получил метод разра-
ботки, основанный на строгом разграничении ролей разработчиков. По-
строение программы можно разделить на две главные стадии:
1. Стадия осознания концептуальной схемы программной задачи—
проектирование . Сюда входит, как общение со специалистами
в предметной области, для которой предназначена данная про-
граммная система, так и построение адекватной инженерной мо-
дели, пригодной для решения данной задачи. Если программный
проект относительно простой, т.е. не требует разбиения программ-
ной системы на несколько изолированных модулей, каждый из
которых решает свою подзадачу, то обычно, концептуальная схе-
ма предметной области задачи не формализуется, сразу пишется
код программы или блок-схема алгоритма решения задачи. Но,
если программная система большая, то такая формализация обя-
зательно необходима. Для программной системы жизненно важно
строго определить, каким образом будут взаимодействовать меж-
ду собой ее различные модули, т.е. выработать протокол взаи-
модействия. Для этого, прежде всего, необходимо строго описать
программную модель данной задачи, которая есть ни что иное,
как ее концептуальная схема. Для построения таких формальных
описаний необходимы соответствующие специалисты, таким обра-
зом, появилась новая специальность в инженерии программиро-
вания— проектировщик программного обеспечения или архитек-
тор программных систем.
2. Кодирование. На основании осознанной концептуальной схемы
можно писать программный код. Этим также обычно занимают-
ся соответствующие специалисты,— кодеры. Можно сказать, что
кодер— это программист, обязанностью которого является напи-
сание программного кода на том или ином языке программирова-
ния в соответствии с предоставленной проектировщиком специфи-
кацией программной модели. Работа «чистого» кодера, конечно,
скучная и не творческая, поэтому часто кодеры также выполняют
какие-то частные задачи проектирования, из тех, что связаны с
конкретным языком программирования. В такие задачи входит,
например, разработка иерархии типов и спецификация интерфей-
са между ними.
Итак, стадия проектирования с нашей точки зрения представляет собой
ни что иное, как построение онтологии задачи, решению которой по-
67
священа данная программная система. Существуют развитые инстру-
менты для осуществления этой стадии разработки. Также, придуманы
языки спецификации программных моделей. Мы рассмотрим один та-
кой язык— UML.
Унифицированный Язык Моделирования UML (Unified Modeling
Language) [26] представляет собой графический язык, созданный специ-
ально для проектирования программных моделей. Язык UML графиче-
ский, это означает, что элементы языка представляют собой различно-
го рода изображения— комбинацию графических значков с текстом, а
описание программных моделей производится с помощью диаграмм ,—
комбинированных схем, составленных из элементов языка UML. Уни-
фицированный Язык Моделирования был создан в компании Rational
Software [15] в 1995 году двумя ее сотрудниками Гради Бутчем и
Джеймсом Рамбо. Язык UML был создан на основе двух языков: языка
проектирования программного обеспечения Booch (Гради Бутч) и язы-
ка анализа программ OMT (Object Modeling Technique) (Джеймс Рам-
бо). В январе 1997 года вышла спецификация языка UML 1.0, создан-
ная уже в результате сотрудничества многих компаний, среди которых
были такие известные корпорации, как Microsoft и Oracle Corporation.
UML быстро стал популярным и на протяжении почти 10 лет являлся
практически единственным широко применяемым языком такого рода.
Приведем краткое описание языка UML [на основе 44]. Для специ-
фикации программных моделей в языке UML используются три вида
диаграмм:
Структурные диаграммы (Structure Diagrams) используются для
спецификации структуры программной модели. Основным элементом,
на основе которого строятся структурные диаграммы, является класс.
Класс представляет собой совокупность атрибутов (свойств) и операций
(методов). Фактически, класс представляет собой набор свойств, т.е. по-
нятие в Аристотелевской традиции. Операции специфицируют, каким
образом будет производится взаимодействия с экземплярами класса,
которые в терминологии языка UML называются объектами . С каж-
дым классом можно также связать описание того, для чего он необ-
ходим— так называемые обязанности (responsibilities). Каждый класс
также имеет уникальное имя, которое используется для того, чтобы
отличать классы друг от друга. Изображается класс посредством пря-
моугольника, разделенного на четыре части. В верхней части пишется
имя класса, во второй сверху части перечисляются его атрибуты (на
каждый атрибут выделяется одна строка), в третьей части перечис-
ляются операции с классом и четвертая часть содержит описание его
обязанностей. Между классами можно вводить отношения . В языке
68
UML существует три типа отношений:
∙ Отношения зависимости(dependency). Зависимостью называют

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

подтип с его родительским типом. В UML используются терми-
ны суперкласс и субкласс для типов и их подтипов, соответствен-
но. Например, «прямоугольник»— это четырехугольник с углами
в 90 градусов, а «ромб»— это четырехугольник с равными сторо-
нами. Классы «прямоугольник» и «ромб» являются субклассами
суперкласса «четырехугольник».
∙ Отношения ассоциации
(association). Это отношение выражает
структурные связи между объектами: комнаты состоят из стен,
в которые могут быть встроены двери и окна.
Каждый из приведенных типов отношений имеет в UML свои подвиды,

но здесь мы не будет в это углубляться, чтобы не уводить читателя
от основного повествования. Классы специфицируются в диаграммах
специального вида— диаграммах классов. Диаграммы классов содер-
жат описания классов и отношений между ними. В UML также ис-
пользуются диаграммы объектов, в которых изображаются экземпля-
ры классов и отношения между ними в какой-то момент времени. Объ-
ект изображается прямоугольником, в котором сначала пишется имя
объекта, а затем, через двоеточие, имя класса, экземпляром которого
данный объект является. Далее под горизонтальной чертой перечис-
ляются конкретные значения атрибутов класса. Классы в UML можно
объединять в пакеты, определяя, таким образом, еще один уровень мо-
дульности. Пакет изображается прямоугольником, у которого слева на
верхней стороне приклеен маленький прямоугольник с именем пакета.
Имена классов пакета перечислены внутри большого прямоугольника.
Классы в пакетах могут быть доступны извне, тогда перед именем клас-
са ставится плюс, или недоступны,— тогда перед именем класс ставится
минус. Также специфицируется внешний доступ и к атрибутам классов.
Пакеты специфицируются на диаграммах пакетов. Все виды структур-
ных диаграмм перечислены в списке ниже:
∙ Классов (Class).
69
∙ Компонентов (Component ).
∙ Композитной структуры (Composite structure).
– Кооперации (Collaboration) (UML 2.0)

∙ Развертывания (Deployment).
∙ Объектов (Object).
∙ Пакетов (Package).
Диаграммы поведения (Behavior Diagrams). Имеется три вида

диаграмм поведения:
∙ Деятельности (Activity). На диаграммах этого показано разло-

жение некоторой деятельности на ее составные элементы. Под
деятельностью (activity) понимается спецификация исполняемого
поведения в виде взаимосвязанного последовательного и парал-
лельного выполнения подчиненных элементов— вложенных видов
деятельности и отдельных действий (action), соединенных между
собой потоками, которые идут от выходов одного узла ко входам
другого. Диаграммы деятельности используются при моделирова-
нии бизнес-процессов, технологических процессов, последователь-
ных и параллельных вычислений. Диаграммы деятельности очень
похожи на диаграммы состояний, если под состояниями понимать
отдельные действия, а потоки выполнения воспринимать как пе-
реходы между состояниями, только в последних нет возможно-
сти моделирования параллельного выполнения действий. Также,
в диаграммах деятельности можно разделить потоки выполнения
надорожки , каждая из которых представляет структурную еди-
ницу учреждения, отвечающую за данную деятельность.
∙ Состояний (State Machine). Другое название этого вида диа-

грамм— диаграмма автомата (State Machine). Диаграммы такого
вида представляют собой, фактически, конечный автомат, в ко-
тором задано поведение программной системы. В отличии от ко-
нечного автомата, диаграмма состояний может иметь также так
называемые составные состояния. Состояние диаграммы автома-
та может иметь имя, которое используется, чтобы отличать со-
стояние друг от друга, действия, которые выполняются при входе
(выходе) в (из) данное состояние, внутренние переходы и подсо-
стояния, если состояние составное, отложенные события— список
70
событий, которые не обработаны в данном состоянии и поставле-
ны в очередь для обработки в других состояниях. Под событием в
контексте диаграммы состояний понимается некий стимул, иници-
ирующий переход из одного состояний в другое. Событием может
быть, например, истечение промежутка времени, после которо-
го объект переходит из состояния ожидания в новое состояние.
Другой пример события— это прерывание от аппаратуры в ком-
пьютере, когда пользователь нажал какую-то кнопку, или пришел
пакет данных по сети.
∙ Прецедентов (Use case). Это диаграммы, на которых отражены
отношения, существующие между актерами и прецедентами7 . Ос-
новная задача диаграммы прецедентов— предоставить средство,
дающее возможность заказчику, конечному пользователю и раз-
работчику совместно обсуждать функциональность и поведение
программной системы. Диаграммы прецедентов обычно включа-
ют в себя:
– Прецеденты. Под прецедентом понимается способ исполь-
зования программной системы внешним пользователем. На-
пример, если программная система— это сотовый телефон, то
в ней могут быть следующие прецеденты: позвонить, принять
звонок, прочитать электронную почту, принять дополнитель-
ный звонок и использовать планировщик.
– Актеры. Это классы внешних пользователей программной
системы. Классы организуются по ролям, которых обычно
немного. Например, для сотового телефона есть всего два
актера: пользователь и сотовая сеть.
– Отношения зависимости, обобщения и ассоциации. Между
прецедентами и актерами могут вводиться различные от-
ношения. Например, прецедент «принять дополнительный
звонок» зависит от прецедента «принять звонок» так как
принять дополнительный звонок можно только, если какой-
то звонок уже принят пользователем. Для банковской про-
граммной системы можно ввести разновидности клиентов:
7 Актеры представляют собой элементы модели, играющие некоторую роль в
моделируемом процессе. Прецедент— это вариант использования системы. Напри-
мер, в качестве актера банковской системы может выступать клиент банка, снима-
ющий деньги со счета. Тогда, банковская система используется в варианте работы с
клиентом. Другой агент в банковской системе— это внешняя программа, например,
программа банкомата, которая выступает от имени пользователя и соединяется с
банковской системой извне.
71
индивидуальный клиент и корпоративный клиент. Это, оче-
видно, уже требует введения отношение обобщения между
актерами «индивидуальный клиент» и «корпоративный кли-
ент», с одной стороны, и актером «клиент»— с другой.
Как видно из описания диаграмм выше, поведение системы описывает-

ся в языке UML тремя способами: рассматриваются деятельность систе-
мы, включающая описание работы структурных подразделений учре-
ждения и параллельной работы нескольких компонентов программной
системы, специфицируется поведение объектов данного класса, органи-
зованная в виде состояний и переходов между ними, а также рассматри-
вается поведение всей программной системы, инициированное внешним
воздействием.
Диаграммы взаимодействия (Interaction Diagrams). Основными
видами диаграммам взаимодействия в языке UML являют диаграммы
последовательностей (sequence) икооперации (collaboration). На диа-
граммах взаимодействий специфицируются связи, включающие мно-
жества объектов и отношений между ними, в том числе сообщения,
которыми обмениваются объекты. Диаграммы последовательностей ак-
центируют внимание на временной упорядоченности сообщений, а диа-
граммы кооперации— на структурной организации посылающих и при-
нимающих сообщения объектов. Диаграммы взаимодействия модели-
руют динамические процессы, а делать это можно двумя разными спо-
собами, соответствующими подвидам диаграмм взаимодействия. Для
лучшего понимания рассмотрим пример. Пусть процесс представляет
собой фильм. С одной стороны, фильм— это последовательность кадров
на кинопленке, т.е. то, что обычно изображается диаграммой последо-
вательностей. С другой стороны, фильм создавался съемочной груп-
пой, писался сценарий, планировались сцены, декорации и т.п. вещи—
аналог диаграммы кооперации.
На диаграммы последовательностей объекты, которые участвуют во
взаимодействии, располагают по оси X, инициирующий взаимодействие
объект размещается слева, остальные объекты правее. Затем вдоль оси
Y размещаются сообщения, посылаемые и принимаемые объектами,
причем эти сообщения упорядочены по времени— более поздние сооб-
щения оказываются ниже. Для каждого объекта на диаграмме последо-
вательности показана его линия жизни . Это вертикальная пунктирная
линия, отражающая существования объекта во времени. Большая часть
объектов существует на протяжении всего взаимодействия, поэтому ли-
нии их жизней рисуются до нижнего края диаграммы. Начала линий
жизни обычно разнятся, так как создание объектов часто инициируется
72
другими объектами. Также, на линии жизни объектов рисуется так на-
зываемый фокус управления. Он изображается в виде вытянутого пря-
моугольника, показывающего период времени, на протяжении которого
объект выполняет какое-либо действие. Верхняя грань прямоугольника
выравнивается по временной оси с моментом начала действия, а ниж-
няя— с моментом его окончания.
Диаграмма кооперации акцентирует внимание на организации объ-
ектов, принимающих участие во взаимодействии. Объекты на диаграм-
мах этого вида располагаются в виде вершин графа, а связи между объ-
ектами изображаются дугами этого графа. Связи также дополняются
сообщениями, которые объекты принимают и посылают. Диаграммы
кооперации имеют два свойства, которые отличают их от диаграмм по-
следовательности:
1. Путь. Для описания связи одного объекта с другим к дальней
концевой точке этой связи можно присоединить так называемый
стереотип пути (например, local, показывающий, что помеченный
объект является локальным по отношению к отправителю сооб-
щения).
2. Порядковый номер сообщения. Для обозначения временной после-
довательности перед сообщением можно поставить номер, кото-
рый должен обязательно возрастать для каждого нового сообще-
ния.
Диаграммы последовательностей и кооперации описывают одну и
ту же информацию, только под немного разными углами зрения. Сле-
довательно, можно сказать, что эти виды диаграмм семантически экви-
валентны. Значит, диаграмму одного вида можно преобразовать в диа-
грамму другого без потери информации. Хотя это, конечно, не означает,
что на диаграммах обоих видов представлена одна и та же информа-
ция. Диаграммы последовательностей и кооперации используют одну
и ту же модель, но визуализируют ее различные особенности.
В языке UML 2.0 также введены новые виды диаграмм взаимодей-
ствия:
∙ Диаграмма обзора взаимодействия (Interaction overview) пред-
ставляет собой разновидность диаграммы деятельности, включа-
ющая фрагменты диаграммы последовательности и конструкции
потока управления.
∙ Диаграмма синхронизации
(Timing)— это альтернативное пред-
ставление диаграммы последовательности, явным образом пока-
73
зывающее изменения состояния на линии жизни с заданной шка-
лой времени. Может быть полезна в приложениях реального вре-
мени.
Конечно, по изложенному здесь описанию языка UML трудно до

конца уяснить методологию его использования, но на эту тему имеется
большое число книг [см., например, 44]. Для больших проектов фор-
мирование их описаний составляет наиболее трудоемкую часть проек-
тирования (по сравнению с программированием). Более того, имеется
несколько систем, в которых по описанию на языке UML автомати-
чески создаются тексты программ, соответствующие этим описаниям.
Однако, на этапе отладки программ программисты могут вносить изме-
нения в программы, которые автоматически в документацию проекта
на языке UML не вносятся. Поэтому для синхронизации документаций
требуется поддержка дисциплины проектирования.
Методология Грубера
В данном разделе мы рассмотрим методологию построения онтологий,
предложенную Томасом Грубером в его статье «Предполагаемые прин-
ципы проектирования онтологий, используемых для обмена знаниями»
[54]. Многие из читателей наверняка знакомы с принципами построе-
ния реляционных баз данных: база данных поэтапно приводится к нор-
мальному виду и на каждой стадии производится определенное пре-
образование— база данных преобразуется к так называемым нормаль-
ным формам. Подобная методология предложена Грубером для постро-
ения онтологий, который предложил проектировать онтологии исходя
из следующих принципов
:
1. Ясность (Clarity). Онтология должна, насколько это возможно

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

мой, т.е. выводы, которые можно сделать из определения понятий
и соотношений между ними, должны быть совместимы с первона-
чальными определениями. Совместимость также должна поддер-
живаться и для описанных неформально понятий. Если выводы,
74
сделанные из формальных определений, несовместимы с нефор-
мальными описаниями, то онтология считается несовместимой.
3. Расширяемость (Extendibility). Онтология должна быть спроек-
тирована так, чтобы ее без дополнительных усилий можно было
бы использовать в разделяемых библиотеках онтологий. Одним
из наиболее важных условий такого проектирования является воз-
можность определения новых понятий на основе существующих в
онтологии элементов так, чтобы это не требовало изменения по-
следних.
4. Минимальная зависимость от кодирования (Minimal encoding
bias). Проектируемая концептуальная схема не должна зависеть
от конкретного языка, который используется для записи форма-
лизованного описания. Зависимость от кодирования возникает в
том случае, когда выбор онтологического представления основы-
вается на совместимости с нотацией языка, на котором записыва-
ется онтология. Эта зависимость должна быть минимизирована,
чтобы различные базы онтологий, использующие другие языки,
могли без затруднений понимать проектируемую онтологию.
5. Минимальная онтологическая фиксация (Minimal ontological
commitment). Онтология должна, насколько это возможно мень-
ше, содержать фактов об онтологии мира, который моделируется,
предоставляя, таким образом, свободу использования данной он-
тологии в других онтологиях. Если концептуальная схема задачи
такова, что описание онтологии мира существенно необходимо, то
это описание должно быть по возможности минимальным. Стоит
ограничиться только перечислением терминов понятий, не опре-
деляя соотношения между ними, т.е. построить «слабую» теорию
в терминах Грубера. Тогда различные базы онтологий, определя-
ющие онтологии мира по своему, смогут придать этим понятиям
свой смысл.
Рассмотрим иллюстративный пример. Моделирование инженерных
систем— часто встречающаяся на практике задача. Инженеры исполь-
зуют различные математические модели, например, системы уравне-
ний, чтобы отразить поведение физических систем. Наиболее важными
понятиями в онтологиях, описывающих концептуальные схемы физи-
ческих систем и их математические модели, являются:
∙ Физическая величина (physical-quantity): 3 метра, 80 километ-
ров в час.
75
∙ Физическая размерность (physical-dimension): длина или дли-
на/время.
∙ Единица измерения (unit-of-measure): метры, километры в час.

∙ Величины (magnitudes) различных порядков: скаляры, вектора,
тензоры и их функции.
∙ Алгебры (algebras) для описания различных математических

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

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

. Мы не будем здесь
использовать металингвистические описания, имея ввиду иллюстратив-
ные цели данного примера. Приведем несколько вариантов такой онто-
логии, начиная с простейшего, и улучшая характеристики онтологии
от варианта к варианту и на основе приведенных выше принципов про-
ектирования. Для построения онтологий мы будем использовать язык
KIF, краткое описание которого было дано выше.
Вариант 1. Физическую величину будет представлять парой
(число, единица измерения). Число будет представлено в форма-
те с плавающей точкой двойной точности, т.е. будет иметь тип
double float. Мы определим physical-quantity как объект, состо-
ящий из значения и единицы измерения, для чего введем две одно-
местные функции: quantity-magnitude и quantity-unit. Определе-
ние типа physical-quantity содержит также требование о том, что
значение и единица измерения физической величины должны суще-
ствовать, что задается предикатом defined. Также, ввиду того, что
physical-quantity задается через условие «тогда и только тогда»
(<=>), мы считаем каждую такую пару значения и единицы измере-
ния физической величиной. Единицы измерения перечисляем явным
образом в определении.
(defrelation physical-quantity
(<=> (physical-quantity ?q)
(and (defined (quantity.magnitude ?q))
(double-float (quantity.magnitude ?q))
(defined (quantity.unit ?q))
76
(member (quantity.unit ?q))
(setof метр секунда килограмм
ампер кельвин моль канделла))))
Итак, physical-quantity представляет собой класс (одномест-

ное отношение, которое выполняется для вех экземпляров класса).
Для описания экземпляров данного класса необходимо определить
конструктор как функцию под названием the-quantity. Выражение
(the-quantity ?m ?u) означает физическая величина ?q со значением
?m и единицей измерения ?u.
(deffunction the-quantity
(and (defined (the-quantity ?m ?u))
(= (the-quantity ?m ?u) ?q)
(and (physical-quantity ?q)
(= (quantity.magnitude ?q) ?m)
(= (quantity.unit ?q) ?u))))
Конкретный экземпляр физического количества можно задать, на-

пример, так:
(= X (the-quantity 3 метр))
Приведенное выше определение понятия физическая величина на

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

double float. Этот тип может в различных онтологиях ко-
дироваться по разному, в зависимости от того, на каком типе
машин реализована данная онтология, или от того, какую
величину точности определили программисты при ее реализа-
ции. Это, очевидно, есть противоречие принципу минимальной
зависимости от кодирования .
2. Понятие единицы измерения определено выше как множество воз-

можных величин для функции quantity.unit. Это также представ-
ляет собой нарушение принципа минимальной зависимости от
77
кодирования, но более тонкое, нежели в предыдущем случае. Име-
ется ввиду, что определение множества возможных значений по-
нятия единица измерения закодировано в определении понятия
физическая величина.
3. Также, фиксированное определение множества возможных значе-
ний единица измерения ограничивает расширяемость онтологии.
Необходимо определить понятие единица измерения так, чтобы
затем легко можно было бы добавлять новые единицы измерения.
Вариант 2. Рассмотрим, каким образом можно устранить ука-
занные выше недостатки. Сначала, изменим определения типа
physical-quantity таким образом, чтобы понятия значения и единицы
измерения были определены независимо. Для этого введем два незави-
симых класса: magnitude и unit-of-measure.
(defrelation physical-quantity
(and (defined (quantity.magnitude ?q))
(magnitude (quantity.magnitude ?q))
(unit-of-measure (quantity.unit ?q)))))
Класс magnitude определим так, чтобы он включал в себя класс дей-

ствительных чисел. Действительные числа будут представлены клас-
сом real-number, определенным в библиотеке онтологий Ontolingua.
Такое определение позволит избежать зависимости от кодирования ти-
па double float.
(defrelation magnitude
(<= (magnitude ?x)
(real-number ?x)))
Заметим, что определение класса magnitude неполное — необходимое

(<=), но не достаточное. Оно говорит, что все действительные числа—
это значения, но не утверждает, что все значения— это действительные
числа. Поэтому класс открыт для введения других типов значений.
Определение понятия единица измерения несколько сложнее. Сна-
чала мы определим примитивный (не содержащий определений аксиом)
класс unit-of-measure:
(defrelation unit-of-measure
(class unit-of-measure))
78
Теперь, на основе этого класса, можно построить механизм расши-
рения множества значений единиц измерения. Для этого введем класс
basic-unit, экземплярами которого будут значения единиц измерения.
Для таких значений определим заодно две операции: unit* (умноже-
ние) и unit^ (возведение в степень) построения новых единиц измере-
ния из существующих. Это удобно, например, когда необходимо изме-
рять площадь плоских фигур (квадратные метры) или скорость (метры
в секунду), для которой операция возведения в степень позволяет опре-
делить единицы измерения заданием отрицательных значений степени
(деление).
(defrelation basic-unit
(=> (basic-unit ?u) ; экземпляры basic-unit отличаются
(unit-of-measure ?u))) ; от экземпляров unit-of-measure
(deffunction unit*
; unit* каждой паре unit-of-measure
; сопоставляет unit-of-measure
(=> (and (unit-of-measure ?u1)
(unit-of-measure ?u2))
(and (defined (unit* ?u1 ?u2))
(unit-of-measure (unit* ?u1 ?u2))))
; операция коммутативна
(= (unit* ?u1 ?u2) (unit* ?u2 ?u1))
; операция ассоциативна
(= (unit* ?u1 (unit* ?u2 ?u3))
(unit* (unit* ?u1 ?u2) ?u3)))
(deffunction unit^
; unit^ каждой паре unit и real
; сопоставляет unit-of-measure
(=> (and (unit-of-measure ?u)
(real-number ?r))
(and (defined (unit^ ?u ?r))
(unit-of-measure (unit^ ?u ?r))))
; выполняются алгебраические свойства
; операции возведения в степень
(= (unit^ ?u 1) ?u)
(= (unit* (unit^ ?u ?r1) (unit^ ?u ?r2))
(unit^ ?u (+ ?r1 ?r2)))
(= (unit^ (unit* ?u1 ?u2) ?r)
(unit* (unit^ ?u1 ?r) (unit^ ?u2 ?r)))
79
Теперь можно определять значения единиц измерения как экзем-
пляры класса basic-unit:
(defobject метр
(basic-unit метр))
(defobject секунда
(basic-unit секунда))
(defobject метр-в-секунду
(= метр-в-секунду
(unit* метр (unit^ секунда -1))))
Приведенное определение выглядит уже достаточно хорошо, значе-

ния и единицы измерения легко расширяемы,— для этого достаточно
определить новый экземпляр класса basic-unit или добавить новый
тип в значения класса magnitude. Единственное, к чему можно было
бы придраться, этонесовместимость различных единиц измерения. В
нашем определении никак не задается, что например, 6 сантиметров
равны 60 миллиметрам, т.е. это не одни и те же сущности в онтологии.
Это тоже можно исправить, изменив соответствующим образом опреде-
ление онтологии. Автор предлагает читателю проделать такое измене-
ние самостоятельно в качестве упражнения. Отметим только, что для
полноценного описания необходимо будет ввести в онтологию понятие
физической размерности .
BORO метод
BORO (Business Object Reference Ontology) методология [см. 21] по-
строения онтологий разработана Крисом Партиджем (Chris Partridge)
[64] в середине 90-х годов прошлого века для решения задачи реор-
ганизации существующих информационных систем в информационные
модели. Крис Партидж работал над этой задачей в течении несколь-
ких лет и в результате выработал методологию построения легких он-
тологий (классификаций) для таких информационных систем с уста-
ревшей структурной организацией. Эта методика получила название
BORO методологии и завоевала популярность благодаря своей простоте
и непритязательности. На основе этой методики была разработана та-
кая известная библиотека онтологий, как обсуждавшаяся выше IDEAS.
Задача реорганизации существующих программных систем встречается
очень часто. Оборудование устаревает довольно быстро, система растет
80
и существующая архитектура перестает удовлетворять новым задачам.
Таким образом, возникает задача реорганизации программной системы.
Задачу реорганизации существующей информационной системы
можно условно разделить на две стадии:
1. Обратная инженерия (reverse engineering). На этой стадии ана-

лизируется существующая система. Из кода и данных выделяют-
ся бизнес объекты и производится их документирование. Таким
образом, производственный процесс, который ведется на данной
стадии, идет в противоположном направлении, нежели тот, что
производился при разработке данной системы. По этой причине,
данная стадия и называется обратной инженерией.
2. Прямая инженерия (forward engineering). На данной стадии, на

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

BORO метод представляет собой набор принципов и правил для
упрощения процесса реинженерии. Основным отличием от обычного
инженерного процесса моделирования здесь является тот факт, что
моделирование производится на основе существующей концептуальной
схемы реорганизуемой программной системы. BORO метод различает
концептуальную схему моделируемого бизнес-процесса и концептуаль-
ную схему производственного процесса, на котором основана логика
работы программной системы. Последняя в BORO методологии счи-
тается более полной и глубокой, нежели концептуальная схема само-
го бизнес-процесса. В этом смысле, в BORO методологии подвергается
критике объектно-ориентированный подход, который дает прямое со-
ответствие между концептуальной схемой бизнес-процесса и его про-
граммной моделью. При таком подходе понятия концептуальной мо-
дели легко могут быть неверно идентифицированы. BORO методоло-
гия дает набор рекомендаций относительно того, каким образом мож-
но идентифицировать понятия концептуальной схемы данной задачи.
BORO методология рассматривает понятия согласно аристотелевской
традиции, т.е. как совокупность свойств-атрибутов. Сущности, облада-
ющие одними и теми же атрибутами считаются принадлежащими од-
81
ному понятию-классу. BORO методология адресована к проблеме пра-
вильного выделения классов. Для этого необходимо проделать следую-
щее:
1. Выделить сущности (индивиды) предметной области. Выделе-

ние производится на основе главного критерия— пространственно-
временной протяженности. Считается, что любой индивид суще-
ствует на основе субстанции (в Аристотелевском смысле), выра-
жающейся в пространственной или временной протяженности.
2. Выделить классы. Любой объект концептуальной схемы, не об-

ладающий пространственной и временной протяженностью, рас-
сматривается как не индивидуальная сущность. Но не каждый
такой объект представляет собой класс.
3. Выделить отношения между элементами предметной области. От-

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

ритм:
Алгоритм 2.1. BORO метод построения онтологии
Вход: Информационная система, на основе которой необходимо
построить информационную модель.
Выход: Информационная модель, записанная в виде онтологии, со-

держащей сущности трех видов: индивиды, классы и отношения (кор-
тежи).
Шаг 1. Выбираем элемент предметной области. Если остались еще

нерассмотренные элементы, то переходим к шагу 2. В противном
случае, заканчиваем работу.
Шаг 2. Если элемент имеет пространственную и временную протя-

женность, то добавляем его в онтологию как индивид и переходим
у шагу 1. В противном случае переходим к шагу 3.
Шаг 3. Если элемент имеет экземпляры, то добавляем его в онтоло-

гию как класс, идентифицируем его экземпляры и переходим к
шагу 1. В противном случае переходим к шагу 4.
82
Страна Протяженность (км) Границы (км)
Китай: 76, Иран: 936, Пакистан: 2430,
Афганистан 5529 Таджикистан: 1026, Туркменистан:
744, Узбекистан: 137
Аргентина 9861
Боливия: 832, Бразилия: 1261, Чили:
5308, Парагвай: 1880, Уругвай: 580
Беларусь 2900
Латвия: 141, Литва: 502, Польша:
407, Россия: 959, Украина: 891
Рис. 2.3: Таблица границ стран мира.
Шаг 4. Если элемент не имеет экземпляров, то это отношение. Запи-

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

кации элементов онтологии концептуальной модели реорганизуемой
информационной системы итеративный. Результирующая онтология
внедрена в онтологию мира посредством рассмотрения пространствен-
но-временных свойств элементов концептуальной схемы информацион-
ной системы. Таким образом, в построенной онтологии не выполнен
пятый принцип построения онтологий Грубера— минимальная онтоло-
гическая фиксация. Процесс выделения не сложен, но онтология, ко-
торая получается в результате, обычно представляет собой простую
классификацию и всегда не содержит соотношений. Хотя BORO метод
в общем случае не применим для моделирования, однако для частных
случаев построения классификаций бизнес-проектов его вполне можно
применять. Для более полного понимания BORO методологии рассмот-
рим иллюстративный пример.
Пусть имеет информационная система, содержащая информацию о
границах стран друг с другом в виде таблицы, малая часть которой по-
казана на рисунке 2.3. Построим на ее основе онтологию по методологии
BORO. Первый столбец таблицы содержит сущности вида Афганистан,
Аргентина и Белоруссия, которые имеют пространственно-временную
протяженность. Поэтому считаем их индивидами. Эти индивиды бу-
дем считать экземплярами класса «страна»,— сущности, находящейся
в первой строке первого столбца. Эта сущность не имеет протяженно-
сти, но имеет экземпляры и поэтому рассматривается как класс. Второй
столбец содержит сущности вида 5529 км, 9861 км и 2900 км, кото-
рые рассматриваются как индивиды. Это экземпляры класса «грани-
ца». Наконец, третий столбец содержит перечисления кортежей— пар,
83
связывающих между собой границы двух стран. Таким образом, ин-
формационная система дает нам в распоряжение факты вида:
∙ Существуют страны.
∙ Каждая из них имеет границы.
∙ Некоторые части границ стран совпадают.
Мы уже ввели в рассмотрение классы «страна» и «граница». Каким об-

разом определить совпадение частей границ некоторых стран? Для это-
го введем два подтипа класса «граница»: «граница страны» и «общая
граница». Тип «страна» связан с типом «граница страны» отношением
часть-целое, которое можно выразить специальным атрибутом класса
«страна». Тип «граница страны» и тип «общая граница» также связа-
ны между собой отношением часть-целое. Таким образом, в результате
имеется четыре класса: «страна», «граница», «граница страны» и «об-
щая граница». Классы «граница» и классы «граница страны» и «общая
граница» связаны между собой отношением таксономии, класс «стра-
на» связан с классом «граница страны» отношением часть-целое, также
как и класс «граница страны» с классом «общая граница». Например,
если имеются два экземпляра класса «страна»: Франция и Бельгия,
то имеются и соответствующие экземпляры класса «граница страны».
Ввиду того, что Франция и Бельгия имеют общую границу, будет суще-
ствовать также и экземпляр класса «общая граница», связанный отно-
шением часть-целое с соответствующими экземплярами класса «грани-
ца страны», эта связь и задает страны, которые имеют общую границу.
1. Алексеева М. Обзор системы Cyc. М.: РГГУ, 2008. http://ezop-

project.wiki.sourceforge.net/Alekseeva_Cyc.
2. Витгенштейн Л. Философские исследования: Кембридж, Январь

1945.
3. Дэвидсон Д. Об идее концептуальной схемы. Пер. А.Л.Золкина

(В кн.: Аналитическая философия. Избранные тексты. (Сост.
А.Ф.Грязнов) М:., Изд-во МГУ, стр. 144-159, 1986.
4. Гоклениус Р. Lexicon philosophicum, quo tanquam clave philisophiae

fores aperiunter. Fransofurti, 1613.
84
5. Домашняя страница Гейнриха Херре. http://www.informatik.uni-
leipzig.de/fk/pers/herre.html
6. Домашняя страница Николо Гуарино. http://www.loa-

cnr.it/guarino.html.
7. Домашняя страница Томаса Битнера.

http://www.acsu.buffalo.edu/ bittner3/Thomas_Bittner.html.
8. Кант И. Критика чистого разума. Сочинения в шести томах. Т.3.

M.:, Мысль, 1964.
9. . Клауберг И. Metaphysika de ente, quae rectus Ontosophia. Амстер-

дам, 1991.
10. Когаловский М., Калиниченко Л. Концептуальное моделирование

и онтолгические модели. В сборнике Онтологическое моделирова-
ния, труды симпозиума в г. Звенигород, 19-20 мая, 2008.
11. Личный сайт Барри Смита. http://ontology.buffalo.edu/smith.
12. Официальный сайт компании Cycorp. http://www.cyc.com.
13. Сайт группы IDEAS. http://www.ideasgroup.org.
14. Сайт исследовательской группы Onto-Med. http://www.onto-

med.de.
15. Сайт компании Rational Software. http://www-

01.ibm.com/software/rational.
16. Сайт Лаборатории Прикладной Онтологии. http://www.loa-cnr.it.
17. Сайт Онтолингва. http://www.ksl.stanford.edu/software/ontolingua/.
18. Сайт онтологии GFO. http://www.onto-med.de/ontologies/gfo.
19. Сайт онтологии SUMO. http://www.ontologyportal.org.
20. Сайт онтологии WebKB-2. http://www.webkb.org/index.html.
21. Сайт, посвященный BORO методологии.

http://www.boroprogram.org.
22. Сайт проекта Открытой Медицинской Онтологии.

http://www.obofoundry.org.
85
23. Сайт проекта BFO. http://www.ifomis.org/bfo.
24. Сайт проекта DOLCE. http://www.loa-cnr.it/DOLCE.html.
25. Сайт проекта WordNet. http://wordnet.princeton.edu.
26. Сайт ресурсов UML. http://www.uml.org.
27. Сайт Рабочей Группы IEEE по Стандартной Онтологии Верхнего

Уровня. http://suo.ieee.org/
28. Сайт семантического Web. http://www.w3.org/2001/sw.
29. Сайт языка LISP. http://www.lispworks.com/documentation/common-

lisp.html.
31. Сайт OWL. http://www.w3.org/TR/owl-ref.
32. Сайт RDF. http://www.w3.org/TR/rdf-syntax-grammar.
33. Страница Дж. Миллера в англоязычной Википедии.

http://en.wikipedia.org/wiki/George_Armitage_Miller.
34. Страница связанных с онтологией SUMO научных работ.

http://www.ontologyportal.org/Pubs.html.
35. Страница таксономии SUMO. http://virtual.cvut.cz/kifb/en/toc/root.html.
36. Философский словарь. Под ред. И.Т. Фролова. 4-е изд., М.: Поли-
тиздат, 445 с, 1981.
37. Хомский Н. Синтаксические структуры. - В кн.: Новое в лингви-

стике. Вып. II. М., 1962.
38. Хомский Н. Язык и мышление. Язык и проблемы знания. М., Из-

дательство МГУ, 1972.
39. OpenCyc— открытый фрагмент онтологии Cyc.

http://www.opencyc.com.
40. Bailey I. Applying a Formal Ontology Approach in Government.

http://www.modelfutures.com/file_download/7/EKIG08-IanBailey-
ApplyingAFormalOntologyApproachInGovt+.pdf.
86
41. Barwise J. Scenes and other situations. The Journal of Philosphy,
78(7):369–397, July 1981.
42. Barwise J and Perry J. Situations and attitudes. The Journal of

Philosophy, 78(11):668–691, November 1981.
43. Bird А. Philosophy of Science London. UCL Press, Montreal: McGill-

Queen’s University Press, p. 124, 1998.
44. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользо-
вателя: Пер. с англ.— М.: ДМК, 2000.
45. Codd E. A Relational Model of Data for Large Shared Data Banks.
Commun. ACM 13(6): pp. 377-387 (1970)
46. Degen W., Heller B., Herre H., Smith B. GOL: Towards
an Axiomatized Upper-Level Ontology. http://www.informatik.uni-
leipzig.de/ herre/papers/gol2001.ps
47. Fonteseca F., Martin J. Learning the differences between Ontologies

and Conceptual Schemas through Ontology-Driven Information
Systems. Journal of the Association for Information Systems— Special
Issure on Ontologies in the Context of IS. Volume 8, Issue 2, Article 3,
February 2007.
48. Gardenfors P. Conceptual Spaces: the Geometry of Thought. MIT

Press, Cambridge, Massachussetts, 2000.
49. Goguen J. What Is a Concept?. ICCS, pp. 52-77, 2005.
50. Goguen J, Harrell F. Foundations for active multimedia narrative:

Semiotic spaces and structural blending. Interaction Studies: Social
Behaviour and Communication in Biological and Artificial systems,
2005.
51. Grenon P. Spatio-temporality in Basic Formal Ontology: SNAP and

SPAN, Upper-Level Ontology, and Framework for Formalization.
http://www.ifomis.org/Research/IFOMISReports/IFOMIS Report
2005_2003.pdf.

87
53. Gruber T. R. A Translation Approach to Portable Ontology
Specifications. Knowledge Acquisition, 5(2): pp. 199-220. (1993)
54. Gruber T. R. Toward Principles for the Design of Ontologies Used for
Knowledge Sharing. International Journal Human-Computer Studies,
43(5-6): pp. 907-928. (1995)
55. Gruber T. R. What is an Ontology? To appear in the Encyclopedia

of Database Systems, Ling Liu and M. Tamer Ozsu (Eds.),
Springer-Verlag, 2008. http://www-ksl.stanford.edu/kst/what-is-an-
ontology.html (2007)
56. Guarino N. Formal Ontology, Conceptual Analysis and Knowledge

Representation. International Journal of Human-Computer Studies,
43(5-6): pp. 625–640. (1995).
57. Guarino N., Formal Ontology in Information Systems. Proceedings of

FOIS’98, Trento, Italy, 6-8 June 1998. Amsterdam, IOS Press, pp. 3-15.
58. Jansen L. Aristotleś Categories. Topoi 26, pp. 153-158, 2007.
59. Heller B., Herre H. Ontological Categories in GOL. In Process Theories:

Crossdisciplinary Studies in Dynamic Categories. Dordrecht. Kluwer
Academic Publishers. pp. 57-76, 2003.
60. Martin. Correction and Extension of WordNet 1.7. In Conceptual

Structures for Knowledge Creation and Communication. Proceedings
11th International Conference on Conceptual Structures, ICCS 2003
Dresden, Germany, July 21-25, 2003.
61. Masolo C., Borgo S., Gangemi A., Guarino N., Oltramari A.,
Schneider L. The WonderWeb Library of Foundational Ontologies
Preliminary Report. http://www.loa-cnr.it/Papers/DOLCE2.1-
FOL.pdf, 2003.
62. Nipkow T., Paulson L., Wenzel M. Isabelle/HOL— A Proof Assistant

for Higher-Order Logic. Springer: LNCS. Vol. 2283, 2002.
63. Newell A. The Knowledge Level. Artificial Intelligence 18, pp. 87-127.
(1982)
64. Partridge K. Business Objects: Re-Engineering for Re-Use. The BORO

Centre; 2Rev Ed edition, 2005.
65. Rosch E. Natural categories. Cognitive Psychology 4, 328-350. (1973)
88
66. Rosch E. Cognitive representations of semantic categories. Journal of
Experimental Psychology: General, 104, pp. 192-233. (1975)
67. Rosch E., Mervis C. B., Gray W., Johnson D., Boyes-Braem P. Basic
objects in natural categories. Cognitive Psychology, 8, pp. 382-439.
(1976)
68. Rosch E. Human categorization. In N. Warren (Ed.), Advances in cross-

cultural psychology (Vol. 1). London: Academic Press. (1977)
69. Smith B. Ontology. In Floridi L. (ed.) The Blackwell Guide to the

Philosophy of Computing and Information. pp. 155-167. 2003.
70. Sowa J. Knowledge Representation: Logical, Philosophical, and

Computational Foundations. Brooks Cole Publishing Co., Pacific
Grove, CA, 2000.
89
3 OWL— язык описания
онтологий для Web
3.1 Необходимость в OWL
В данной главе мы рассмотрим OWL (Web Ontology Language—

Язык Онтологии Web)— язык, созданный для описания онтологии Web
(World Wide Web [9]). World Wide Web— это система связанных друг с
другом с помощью гиперссылок документов, которые можно получить
через Интернет. Гипертекстовый документ отличается от обычного тем,
что он может содержать не только текст, но также и другую информа-
цию: рисунки, музыкальные и видео файлы и т.п. Такие документы
можно просматривать с помощью специальной программы— Web брау-
зера . Автор полагает, что каждый читатель данной книги хоть однажды
просматривал гипертекстовые документы через Web браузер, поэтому
подробное изложение идеологии Web выглядит здесь неблагодарным
занятием. Уделим лучше основное внимание рассмотрению наследника
World Wide Web— так называемого умного Web или Semantic Web [см.
30; 19].
Semantic Web представляет собой следующее поколение World Wide
Web, в котором, кроме гипертекстов, содержатся описания семанти-
ки этих документов, а также описания семантики различных серви-
сов, предоставляющих эти документы конечным пользователям. Такие
описания должны быть понятны не только людям, но и компьютерам,
иначе толку от таких описаний будет немного. Понимание содержимого
Web документов компьютерами дает возможность программам прово-
дить более точный поиск информации в Web, автоматически системати-
90
зировать эту информацию, а также обмениваться такой информацией
с другими программами. Обычно, Semantic Web описывается как ком-
понент грядущей версии Web— так называемого Web 3.01 . Каким будет
Web 3.0 мы пока можем только предполагать, но очевидно, что одним
из главных его компонентов будет Semantic Web, предполагающий опи-
сание семантики Web документов.
Консорциум W3 [9] разработал целую идеологию семантического
Web, включающую в себя определение языков, которые используются
для описаний семантики Web документов, их стандартизацию, а также
предложения по использованию этих языков для описаний конкретных
документов. На сайте консорциума имеется специальный раздел [19],
посвященный Semantic Web. Для описания семантики Web информа-
ции используется язык RDF (Resource Description Framework) [2; 30],
мы его рассмотрим далее подробно. Этот язык имеет своим предназна-
чением описание ресурсов Web документов, но для выражения полно-
ценных онтологий его недостаточно. Поэтому, был предложен также и
специальный язык описания онтологии Web— язык OWL [3; 30]. Этот
язык совместим с языком RDF, т.е. каждый OWL документ является
также и RDF документом. Язык RDF построен на синтаксисе языка
XML [4], использующегося в Web в качестве стандарта для обмена дан-
ными. Поэтому, каждый OWL документ является также и корректным
XML документом. Далее мы рассмотрим также принципы языка XML.
Читатель наверняка уже догадался, почему описание языка OWL
присутствует в книге, посвященной прикладным онтологиям. Описа-
ние семантики Web в полной мере соответствует определению онтоло-
гии, данному в первой главе. Все онтологии Web имеют один и тот же
смысловой оттенок, который диктует цель написания этих докумен-
тов— публикация информации в Сети. С этой точки зрения все онтоло-
гии конкретных документов и сервисов Web могут быть объединены в
единую онтологию— онтологию Web. Язык OWL, как представляется
1 Термин Web 3.0 используется для обозначения следующего за Web 2.0 поколе-
ния World Wide Web. Термином Web 2.0 обозначают текущее состояние Web, которое
принципиально отличается от того, в котором Web находился при его зарождении. С
самого начала Web задумывался как распределенное по всему миру хранилище ги-
пертекстовых документов, таковым Web остается и сегодня. Но, с начала нынешнего
века, с ростом числа пользователей, Web превратился так и в социальный феномен.
Сегодня, популярными сервисами являются не только те, которые предоставляют
информацию, но и те, которые просто обеспечивают общение пользователей друг
с другом. Такие сервисы получили название социальные сети. Социальная сеть—
совершенно новый феномен, который отличается от сети обычных гипертекстовых
документов, как по принципам использования, так и по идеологии. Web социальных
сетей— это Web 2.0.
91
его авторам, предназначен, главным образом, для описания этой он-
тологии. Конечно, OWL можно использовать и для описания других
онтологий, как мы увидим далее, разработан даже специальный редак-
тор Protege, позволяющий удобно набирать информацию относительно
содержимого онтологий, описываемых на языке OWL.
3.2 Язык XML
XML (Extensible Markup Language [4]) представляет собой диалект язы-

ка SGML (Standard Generalized Markup Language— Стандартный Обоб-
щенный Язык Разметки [1]), который, в свою очередь, является на-
следником разработанного в IBM в 1969 году языка GML (Generalized
Markup Language— Обобщенный Язык Разметки). SGML представляет
собой метаязык, на котором можно задавать языки разметки докумен-
тов. Изначально, SGML создавался для разметки государственной до-
кументации США, чтобы последняя могла читаться компьютерами. В
этом качестве, SGML использовался в правительственных и аэрокос-
мических учреждениях США. Главный недостаток языка SGML— это
его сложность. Вероятно, поэтому стал популярным его упрощенный
диалект— язык XML. Рассмотрим принципы построения документов на
этом языке.
Основным элементом языка XML является так называемый тэг —
последовательность символов, которая используется непосредственно
для разметки документа. Тэг представляет собой имя, заключенное в
угловые скобки, например: <name>. Различают начальный (start-tag)
и заключающий (end-tag) тэги. Заключающий тэг должен иметь то же
имя, что и его начальный, но это имя должно предваряться косой чер-
той. Например:
<name>содержимое тэга</name>
Содержимое тэга— это обычно простой текст (который может быть пу-
стым), но также может иметь и более сложную структуру. Начальные
тэги могут иметь атрибуты, которые представляют собой пары вида
(имя, текст), и используются для задания дополнительной информа-
ции отмечаемому участку текста. Например,
<termdef id="dt-dog" term="dog">

Тэги могут вкладываться друг в друга, т.е. в содержимом одного тэга
может присутствовать другой. Таким образом, можно задавать слож-
92
ные структуры документов. Главным требованием является то, чтобы
тэги были вложены друг в друга целиком, приведем пример:
<tag1>
<tag2>
</tag1>
</tag2>
Такая структура не верна, тэги не вложены, а перекрывают друг друга.
Вот пример корректной структуры:
<tag1>
<tag2>
</tag2>
</tag1>
Более того, тэги документа должны образовывать древовидную струк-
туру, т.е. должен быть один главный тэг всего документа, в который
вкладывается размечаемый текст и все другие тэги. Таким образом,
XML документ представляется деревом, элементы которого— это тэги
и размечаемые ими участки текста, вершина дерева отмечена главным
тэгом документа. Приведем пример размеченного документа, в котором
содержится информацию о пользователях:
<user-list>
<user>
<id>1</id>
<fname>Иван</fname>
<sname>Брусенко</sname>
<age>39</age>
<sex>Мужской</sex>
</user>
<user>
<id>2</id>
<fname>Шамиль</fname>
<sname>Галимов</sname>
<age>37</age>
</user>
<user>
<id>3</id>
<fname>Татьяна</fname>
<sname>Волкова</sname>
93
<age>23</age>
<sex>Женский</sex>
</user>
</user-list>
Информацию о конкретном пользователе можно было бы задать и с
помощью атрибутов:
<user-list>
<user id="1" fname="Иван" sname="Брусенко"
age="39" sex="Мужской"/>
<user id="2" fname="Шамиль" sname="Галимов"
age="37" sex="Мужской"/>
<user id="3" fname="Татьяна" sname="Волкова"
age="23" sex="Женский"/>
</user-list>
Здесь, ввиду того, что содержимое тэга пусто, не используются заклю-
чающие тэги, это отмечается косой чертой, которая ставится перед за-
крывающей угловой скобкой.
Документы XML, синтаксис которых удовлетворяет перечислен-
ным выше базовым требованиям, называются правильно построенным
(well-formed). Можно еще ограничить структуру документа, определив
вид дерева тэгов документа. XML унаследовал один из способов такого
определения от языка SGML. Способ заключается в том, что струк-
тура документа задается в его начале в виде так называемого DTD
(Document Type Definition— Определение Типа Документа). DTD имеет
свой специфический синтаксис, который мы здесь описывать не будет,
приведем только иллюстративный пример:
<!DOCTYPE user-list [
<!ELEMENT user-list (user*)>
<!ELEMENT user (id, fname, sname, age, sex)>
<!ELEMENT id (#PCDATA)>
<!ELEMENT fname (#PCDATA)>
<!ELEMENT sname (#PCDATA)>
<!ELEMENT age (#PCDATA)>
<!ELEMENT sex (#PCDATA)>
]>
<user-list>
<user>
94
<id>1</id>
<age>39</age>
</user>
<user>
<id>2</id>
<age>37</age>
</user>
<user>
<id>3</id>
<age>23</age>
</user>
</user-list>
В определении типа документа говорится, что главным его тэгом
должен быть тэг user-list, который содержит ноль или боль-
ше тэгов user. Каждый тэг user должен содержать четыре тэга
(fname, sname, age, sex), причем именно в заданной последователь-
ности. Документ XML, который согласуется с определением его струк-
туры, называется действительным (valid).
Хотя, изначально язык XML задумывался для разметки докумен-
тов, сейчас этот язык используется в принципиально ином качестве.
Документы XML сейчас чаще всего служат текстовым представлени-
ем данных, которые необходимо передать с одного компьютера на дру-
гой. Иначе говоря, если раньше язык XML использовался для разметки
документов, которая была бы понятна компьютерам, то сейчас XML
используется для преобразования уже структурированных данных в
последовательную (текстовую) форму и обратно. Это новое качество
использования языка диктует к нему новые требования. Так, напри-
мер, необходимо с максимальной тщательностью установить формат
написания чисел в XML документах. Ведь числовые данные будут пре-
образовываться в текстовый вид и обратно, и при этом не должно быть
никаких потерь. Версия языка XML, унаследованная от SGML, таких
95
возможностей не предоставляет. Поэтому, язык XML был существенно
переработан, в языке появились типы, различные форматы представ-
ления данных различных типов и другие необходимые для передачи
данных свойства. Также, определение структуры документа с помо-
щью DTD было заменено на более подходящий способ, носящий назва-
ние XML схема (XML schema). Схема представляет собой определе-
ние структуры данных, которые передаются в данном XML документе,
причем это определение задается на языке XML. В схеме документа
можно задать новые типы, можно использовать уже определенные в
схеме самого языка XML. Схемы можно хранить распределенно в раз-
ных местах Интернет и загружать их по мере необходимости. Приведем
полный рабочий пример XML документа, который используется для пе-
редачи данных о пользователях:
<?xml version="1.1" encoding="UTF-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="user-list" type="User-list"/>
<xs:complexType name="User-list">
<xs:sequence>
<xs:element name="user" type="User"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="User">
<xs:sequence>
<xs:element name="id" type="xs:decimal"/>
<xs:element name="fname" type="xs:string"/>
<xs:element name="sname" type="xs:string"/>
<xs:element name="age" type="xs:decimal"/>
<xs:element name="sex" type="xs:string"/>
</xs:sequence>
</xs:complexType></xs:schema>
</xs:schema>
<user-list>
<user>
<id>1</id>
<age>39</age>
96
</user>
<user>
<id>2</id>
<age>37</age>
</user>
<user>
<id>3</id>
<age>23</age>
</user>
</user-list>
3.3 Язык RDF
RDF (Resource Description Framework— Среда Описания Ресурсов [2;

30]) представляет собой язык, позволяющий описывать информацию,
расположенную в Web. В Semantic Web, когда говорят о каких-то сущ-
ностях Web, называют эти сущности ресурсами
. RDF представляет со-
бой язык для описание таких ресурсов. Ввиду того, что описания се-
мантики документов должны пониматься компьютерами, необходимо
разработать специальные программы-агенты, которые бы производи-
ли такое чтение. Также, необходимо обеспечить возможность обмена
информацией между различными программными агентами. Таким об-
разом, под RDF подразумевается не только сам язык, но также и раз-
личные дополнительные программные модули, необходимые для обес-
печения полноценного чтения и обмена информацией, записанной на
этом языке. Этот факт подчеркивается в названии языка RDF.
Главный элемент языка RDF— это тройкаили триплет. Тройка
представляет собой совокупность трех сущностей:
1. Субъект.
2. Объект.
3. Предикат.
97
Предикаты еще часто называют свойствами
. Тройка имеет также гра-
фическое представление в виде связи узел-дуга-узел:

Субъект
Предикат- Объект

Рис. 3.1: Представление тройки в виде ребра графа.

Какую информацию хранят тройки? Это зависит от ее содержания. На-
пример, если необходимо хранить информацию о пользователях, как в
примере, приведенном в разделе, описывающем язык XML, то трой-
ка может представлять конкретное значение атрибута пользователя.
Имя атрибута выступает в качестве предиката, субъект— это экзем-
пляр класса «user», а объект— это конкретное значение свойства. В
нашем примере, в качестве уникального идентификатора экземпля-
ра класса «user» можно использовать его атрибут «id». Так, тройка
(fname,1,«Иван») представляет конкретное значение атрибута «fname»
экземпляра с идентификатором «1» класса «user». На самом деле, пе-
ревод классов в совокупность троек осуществляется автоматически, мы
рассмотрим этот механизм подробнее, когда будем изучать расширение
языка RDF— RDF Schema.
С математической точки зрения, тройка представляет собой экзем-
пляр некоторого бинарного отношения. Вообще, отношение— это мно-
жество последовательностей элементов, причем количество элементов
в каждой последовательности фиксированно и равно какому-то заранее
определенному натуральному числу 𝑛. Если 𝑛 = 2, то отношение назы-
вается бинарным. Например, отношение «семейные пары» задает мно-
жество пар элементов вида («муж»,«жена»). Таким образом, конкрет-
ная тройка просто задает одну пару из некоторого отношения, имя кото-
рого также задается в качестве третьего параметра. Для полноценного
описания, кроме задания отношений, необходимо еще задать ограни-
чения на их содержимое. Например, для отношения «семейные пары»
необходимо уточнить, что первый элемент каждой пары этого отноше-
ния должен быть мужчиной, а второй— женщиной2 . Для задания тако-
го ограничения необходимо ввести понятия «мужчина» и «женщина»,
после чего задать ограничение, выражающее тот факт, что если имеется
тройка вида («имя 1», «имя 2», «семейные пары»), то сущность «имя
1» должна быть экземпляром понятия «мужчина», а сущность «имя
2Мир стремительно меняется, и в некоторых странах это требование уже не
является безусловной необходимостью. Последнее, в свою очередь, только подчер-
кивает жизненность философии концептуального релятивизма.
98
2»— экземпляром понятия «женщина». Это делается посредством так
называемых высказываний . Для высказываний существует свой язык,
включающий переменные, логические операции, такие как, логическое
«или» (дизъюнкция), логическое «и» (конъюнкция), логическое следо-
вание (импликация), а также кванторы существования и всеобщности,
позволяющие ограничивать область применения высказывания. Напри-
мер, ограничение выше можно было бы записать так (обозначим отно-
шение «семейные пары» как 𝐹 , а отношения «мужчина» и «женщина»
как 𝑀 и 𝑊 , соответственно.): ∀𝑥, 𝑦𝐹 (𝑥, 𝑦) ⇒ 𝑀 (𝑥) 𝑊 (𝑦)— «для лю-
⋀︀
бых сущностей 𝑥 и 𝑦 , если выполняется 𝐹 (𝑥, 𝑦), то выполняется одно-
временно 𝑀 (𝑥) и 𝑊 (𝑦)». Язык RDF основан на математическом аппа-
ратедескриптивной логики [34], рассмотрим эту логику подробнее.
Дескриптивная логика
Дескриптивная логика (Description Logic— DL) основана на формализ-
мах семантических сетей фреймов
[36] и [21], но использует аппарат
математической логики. В математической логике производится явное
разделение насинтаксис семантику
и . Синтаксис задает язык, с по-
мощью которого записываются различные высказывания об элементах
мира данной логической системы. Семантика задает ту часть описы-
ваемого мира, которая удовлетворяет заданным ограничениям. Таких
частей может быть более одной и даже бесконечно много. Каждая та-
кая часть мира называется моделью данной логической системы. Ча-
сто говорят о дескриптивных логиках, подразумевая под конкретной
дескриптивной логикой некоторую логическую систему, описывающую
какой-нибудь мир. Поэтому, читатель должен различать понятия де-
скриптивной логики как науки, изучающей логические системы опре-
деленного вида, и дескриптивной логики как конкретной логической
системы, чей синтаксис удовлетворяет определенным ограничениям.
Опишем ограничения, налагаемые на синтаксис и семантику дескрип-
тивных логик.
Синтаксис. Язык любой дескриптивной логики состоит из следующих
элементов:
∙ Множество унарных предикатных символов, обозначающих име-

на понятий.
∙ Множество бинарных предикатных символов, обозначающих име-

на ролей
.
99
∙ Рекурсивное определение термов понятий
, задаваемое с помо-
щью конструкторов на основе понятий и ролей.
Понятия обозначают множества сущностей, которые им принадлежат,

т.е. это классы в терминологии первой главы. Роли задают отноше-
ния между понятиями. В качестве конструкторов термов выступают,
как операции логики первого порядка , такие как перечисленные выше
конъюнкция, дизъюнкция, ограничения универсальности и существо-
вания и т.д., так и операции, задающие ограничения на роли, т.е. на
бинарные отношения. В качестве таких ограничений могут выступать
требование к обращению бинарного отношения, т.е. его симметричность
(∀𝑥, 𝑦𝑅(𝑥, 𝑦) ⇒ 𝑅(𝑦, 𝑥)⋀︀
), требование к транзитивности бинарного отно-
шения (∀𝑥, 𝑦, 𝑧𝑅(𝑥, 𝑦) 𝑅(𝑦, 𝑧) ⇒ 𝑅(𝑥, 𝑧)) и т.п. Например, в примере
с пользователями, обсуждавшемся в разделе о языке XML, множество
унарных предикатных символов было бы 𝑈𝑃 = {user}, т.е. содержало
бы имя единственного понятия «user». Множество бинарных предикат-
ных символов— это 𝐵𝑃 = {𝑖𝑑, 𝑠𝑛𝑎𝑚𝑒, 𝑓 𝑛𝑎𝑚𝑒, 𝑎𝑔𝑒, 𝑠𝑒𝑥}.
Семантика. В математической логике в качестве модели логической
системы обычно используется некоторое множество, назовем его 𝑀 .
Каждому элементу множества унарных предикатных символов дается
в соответствие некоторое унарное отношение на этом множестве, а каж-
дому элементу множества бинарных предикатных символов— бинарное
отношение. Иначе говоря, каждому имени понятия соответствует некий
класс— подмножество множества 𝑀 , а каждому имени роли— бинарное
отношение на множестве 𝑀 . Если задаются какие-то ограничения на
отношения, то они должны выполняться на всех отношениях. Каждое
такое задание соответствия между именами и отношениями на мно-
жестве 𝑀 (обозначим его через 𝐼 ) будем называть моделью
данной
дескриптивной логики или ее интерпретацией . В нашем примере о
пользователях, имеем следующую интерпретацию:
∙ 𝑀 = {«Иван», «Брусенко», «Шамиль», «Галимов», «Татьяна»,

«Волкова», «39», «37», «23», «1», «2», «3», «Мужской», «Женский»}.
∙ 𝐼(user) = {(«1»), («2»), («3»)}.
∙ 𝐼(id) = {(«1», «1»), («2», «2»), («3», «3»)}.
∙ 𝐼(fname) = {(«1», «Иван»), («2», «Шамиль»), («3», «Татьяна»)}.
∙ 𝐼(sname) = {(«1», «Брусенко»), («2», «Галимов»), («3», «Волкова»)}.
∙ 𝐼(age) = {(«1», «39»), («2», «37»), («3», «23»)}.
100
∙ 𝐼(sex) = {(«1», «Мужской»), («2», «Мужской»), («3», «Женский»)}.
Интерпретация логической системы в некотором множестве представ-

ляет собой классический подход, но в RDF используется также интер-
претация на графе . Об этом подходе мы поговорим подробно чуть поз-
же.
В дескриптивных логиках проводится различие между так называе-
мыми терминологическим компонентом — TBox (terminological box) и
компонентом суждений — ABox (assertional box). TBox содержит вы-
сказывания, касающиеся иерархии понятий, т.е. задающие отношения
между понятиями, а ABox содержит высказывания, характеризующие
отношения индивидов и понятий. Например, высказывание «каждый
пользователь— это человек» задает отношение между понятиями «ра-
ботник» и «человек», а значит, принадлежит множеству TBox. Вы-
сказывание «Иван является пользователем» задает отношение между
индивидом «Иван» и понятием «человек», и принадлежит множеству
ABox. В дескриптивной логике, элементы множества TBox представ-
ляют собой ограничения, задаваемые исключительно на унарных пре-
дикатах (понятиях), в этом состоит их отличие от высказываний мно-
жества ABox. Различение высказываний на TBox и ABox полезно, если
рассматривать возможность построения процедуры логического выво-
да на моделях дескриптивных логик. Высказывания из TBox задают
свойства «классификации», а высказывания из ABox— свойства, кото-
рые можно условно назвать свойствами «проверки экземпляра». Ло-
гический вывод по этим множествам может существенно различаться
по производительности, поэтому имеет смысл реализовать отдельные
алгоритмы вывода для каждого компонента. Кроме того, множество
TBox можно использовать как интерфейс к программной системе, реа-
лизующей данную дескриптивную логику3 .
Базовым языком для различных дескриптивных логик, использу-
ющихся в семантике Web, является 𝒜ℒ𝒞 (Attributive Language with
Complements— Атрибутный Язык с Дополнениями) [22]. 𝒜ℒ𝒞 состоит
из трех компонентов:
∙ Множества имен базовых классов (NC), а также два специальных

класса: универсальный клас | и пустой клас ⊥.
∙ Множества имен свойств (NR).

3 Иначе говоря, множество TBox можно использовать, как приближенную кон-
цептуальную схему онтологии, которая описывается данной дескриптивной логикой.
Онтология показывается пользователю в виде набора классов и различных связей
между этими классами.
101
∙ Множества имен объектов (NI).
На основе имен базовых классов можно конструировать более слож-

ные классы. В качестве конструкторов новых классов выступают ло-
гические операции конъюнкции, дизъюнкции, отрицания, дополнения,
я также использование кванторов существования и универсальности.
Например, если имеются базовые классы Мать и Отец, то с помощью
операции дизъюнкции соответствующих им предикатов можно опреде-
лить новый класс Родитель. Кроме того, имеются также отношения
класс-подкласс, экземпляр класса и экземпляр свойства. Семантика
𝒜ℒ𝒞 задается интерпретирующей функцией, сопоставляющей каждо-
му классу некоторое множество, а каждому отношению— множество
пар элементов. Очевидно, что 𝒜ℒ𝒞 представляет собой специального
вида дескриптивную логику, в которой в качестве терминологическо-
го компонента (TBox) выступают перечисленные выше аксиомы име-
нования и отношения подкласса, а в качестве компонента суждений
(ABox)— аксиомы конструкции новых классов и выделения экземпля-
ров. На основе языка 𝒜ℒ𝒞 , посредством добавления новых аксиом, так
называемых ограничений, реализованы дескриптивные логики, кото-
рые используются в различных диалектах языка OWL, который по-
дробно будет рассмотрен нами ниже.
В описании дескриптивных логик используются различные аббре-
виатуры, такие как 𝒮ℋ𝒪ℐ𝒩 (𝒟) или 𝒮ℛ𝒪ℐ𝒬(𝒟). Расшифруем смысл
этих аббревиатур.
∙ Буква 𝒮 в названии дескриптивной логики означает, что данная

логика реализована как язык 𝒜ℒ𝒞 , в котором, дополнительно,
можно ввести аксиому транзитивности на отношения.
∙ Сочетание 𝒮ℋ— это логика 𝒮 , в которой поддерживается иерар-

хия (hierarchy) отношений.
∙ 𝒮ℋℐ представляет собой логику 𝒮ℋ, в которой имеется возмож-

ность определять обратные (inverse) отношения для данных отно-
шений.
∙ 𝒮ℋℐℱ — это логика 𝒮ℋℐ с возможностью задавать функциональ-

ные (functional) отношения.
∙ Логика 𝒮ℋℐ𝒩 — это 𝒮ℋℐ , в которой имеется возможность зада-

вать ограничения на размер множеств значений отношений. На-
звание этого ограничения на английском звучит так: non-qualified
number restrictions.
102
∙ 𝒮ℋℐ𝒬— это логика 𝒮ℋℐ , в которой можно задавать ограниче-
ния на размер множеств значений отношений и определять под-
классы из элементов, связанных некоторым отношением с опре-
деленным числом элементов (qualified number restrictions). На-
пример, можно было бы определить класс индивидов, имеющих
более одного автомобиля в собственности следующим образом:
>1 ИмеетАвто Человек.
∙ Логика 𝒮ℋ𝒪ℐ𝒬— это 𝒮ℋℐ𝒬, расширенная возможностью зада-
вать т.н.номиналы . Номиналы— это задание классов в виде пе-
речислений. В описании RDFS используется пример определения
класса Материк посредством перечисления индивидов этого клас-
са (конкретных материков).
∙ Логика 𝒮ℛ𝒪ℐ𝒬— это 𝒮ℋ𝒪ℐ𝒬, в которой имеется возможность

задавать иерархию отношений посредством их композиции.
∙ 𝒮ℛ𝒪ℐ𝒬(𝒟) представляет собой логику 𝒮ℛ𝒪ℐ𝒬, в которую до-

бавлены т.н. типы данных и отношения, значениями которых мо-
гут быть типы данных. Типы данных— это определенные в языке
XML типы, такие как целые и вещественные числа или строки.
Синтаксис RDF
Ввиду того, что RDF предполагается использовать для описания ре-
сурсов, распределенных по разным участкам Web, необходимо как-то
решить проблему идентификации имен узлов и ребер RDF графа, т.е.
элементов троек. Для этого используется стандартный подход: каждый
элемент описывается посредством так называемого Унифицированного
Идентификатора Ресурса (URI— Uniform Resource Identifier [37]). Обыч-
но, URI представляет собой, либо URL (Унифицированный Указатель
Ресурса— Uniform Resource Locator, [38]), содержащий информацию о
местонахождении данного ресурса в Web, либо URN (Унифицированное
Имя Ресурса— Uniform Resource Name, [39]), позволяющего идентифи-
цировать данный ресурс в некотором пространстве имен . Простран-
ство имен представляет собой просто поименованное множество имен и
используется, чтобы обеспечить уникальность этих имен в Web. Напри-
мер, если есть задача объединить два RDF графа (множества троек), и
при этом, в каждом из графов использует свой узел с локальным име-
нем «Иван», то можно разрешить проблему идентификации этих узлов
в объединении графов двумя способами:
103
1. Дать каждому из узлов уникальное имя, используя URL
его RDF графа в Web. Например, если URL первого гра-
фа— это http://www.example.com/graph1#
, а URL второго— это
http://www.example.com/graph2#
, то URI узла «Иван» в пер-
вом графе будет http://www.example.com/graph1#Иван
, URI узла
«Иван» во втором графе— http://www.example.com/graph2#Иван
.
2. Задать для каждого из графов собственное простран-

ство имен и, тогда, имена узлов с локальным именем
«Иван» будут уникальными в объединении графов, т.к.
будут находиться в разных пространствах имен. Напри-
мер, для первого графа задать его пространство имен так:
xmlns:graph1="http://www.example.com/graph1#"
, а для второго
так: xmlns:graph2="http://www.example.com/graph2#"
. Тогда,
полное имя узла «Иван» в первом графе будет graph1:Иван
, а во
втором— graph2:Иван
.
URI позволяют также ссылаться на одни и те же сущности Web из раз-

ных RDF документов. В Semantic Web используются три стандартных
пространства имен:
∙ rdf. В этом пространстве имен задаются имена, которые использу-

ются в RDF. URI для этого имени: http://www.w3.org/1999/02/22-
rdf-syntax-ns#.
∙ rdfs. Здесь задаются имена, используемые в RDF Schema. Его URI:
http://www.w3.org/2000/01/rdf-schema#.
∙ owl. Описываются имена, используемые в OWL. URI для этого
имени: http://www.w3.org/2002/07/owl#.
Чаще всего в RDF используются имена rdf:type, rdf:isInstanceOf

и rdf:Property. Поясним, как они используются, на нашем примере
с таблицей пользователей. Как уже говорилось выше, описать содер-
жимое таблицы с помощью RDF можно следующим универсальным
алгоритмом:
∙ Представить каждую строку таблицы его уникальным идентифи-

катором этой строки. Обычно, это просто номер данной строки в
таблице.
∙ Представить каждое имя столбца как rdf:Property.
∙ Представить имя каждой таблицы как rdf:type.
104
id fname sname age sex
1 Иван Брусенко 39 Мужской
2 Шамиль Галимов 37 Мужской
3 Татьяна Волкова 23 Женский
Рис. 3.2: Таблица пользователей user-list.
В нашем примере имеется следующая таблица:

Опишем имена столбцов как rdf:Property, т.е. скажем, что эти име-
на будут служить предикатами. Предполагается, что все имена опреде-
лены в пространстве имен usr.
(usr:id,rdf:type,rdf:Property)
(usr:fname,rdf:type,rdf:Property)
(usr:sname,rdf:type,rdf:Property)
(usr:age,rdf:type,rdf:Property)
(usr:sex,rdf:type,rdf:Property)
Теперь, для каждой строки зададим «экземпляр» класса «user».
(usr:user1,rdf:type,usr:user)
Здесь мы используем комбинированное имя экземпляра usr:usern, где
n— это идентификатор строки. Перечислим теперь свойства классов.
(usr:user1,usr:id,1)
(usr:user1,usr:fname,Иван)
(usr:user1,usr:sname,Брусенко)
(usr:user1,usr:age,39)
(usr:user1,usr:sex,Мужской)
(usr:user2,usr:fname,Шамиль)
(usr:user2,usr:sname,Галимов)
(usr:user2,usr:sex,Мужской)
(usr:user3,usr:fname,Татьяна)
(usr:user3,usr:sname,Волкова)
(usr:user3,usr:sex,Женский)
105
Заметим, что здесь был использован другой порядок описания трой-
ки, а именно: (субъект, предикат, объект). Этот порядок используется
в качестве стандартной нотации и мы будем его придерживаться далее.
Для описания троек вне документов XML4 используется две стандарт-
ные нотации. Опишем их.
Нотация N-Triple
5
[13]. В данной нотации каждый элемент трой-
ки представляется посредством заключенного в угловые скобки
URI. Элементы идут в порядке «субъект, предикат, объект» и
заканчиваются точкой. Например, если имена из примера выше
расположены по URL=http://www.example.org/user-list#
, то тройка
(usr:user1,rdf:type,usr:user) будет выглядеть так:
<http://www.example.org/user-list#fname>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.example.org/user-list#user>.
Нотация 3 RDF (N3) [15]. Это более компактная нотация, позволяю-
щая определять локальные синонимы URI, которые называются пре-
фиксами и задаются ключевой комбинацией @prefix. Данный способ
записи RDF троек разработан специально для людей и представляет со-
бой гораздо более удобную для человека форму записи, чем XML RDF.
Имена элементов тройки записываются без угловых скобок в порядке
«субъект, предикат, объект» и также заканчиваются точкой. Если под-
ряд записывается несколько троек с одним и тем же субъектом, то в
конце тройки, если она не последняя, ставится точка с запятой, а в кон-
це последней тройки— точка. При этом, имя субъекта ставится только
для первой тройки, в остальные оно подставляется автоматически из
предыдущей. Тройки записываются следующим образом:
@prefix usr <http://www.example.org/user-list#>

@prefix rdf <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
usr:user1 rdf:type usr:user

usr:id rdf:type rdf:Property .

usr:fname rdf:type rdf:Property .
4 Обычно, отличные от XML описания RDF троек используют для удобства: либо
для ручного ввода информации человеком, либо для просмотра примеров.
5 Нотация N-Triple представляет собой упрощенную версию нотации Turtle (Terse
RDF Triple Language) [см. 14].
106
usr:sname rdf:type rdf:Property .
usr:age rdf:type rdf:Property .
usr:sex rdf:type rdf:Property .
usr:user2 usr:id "1" ;

usr:fname "Иван" ;
usr:sname "Брусенко" ;
usr:age "39" ;
usr:sex "Мужской" .

usr:fname "Шамиль" ;
usr:sname "Галимов" ;
usr:age "37" ;
usr:sex "Мужской" .

usr:fname "Татьяна" ;
usr:sname "Волкова" ;
usr:age "23" ;
usr:sex "Женский" .
Запись троек в XML документах производится несколько иначе,
нежели в рассмотренных выше нотациях6 . Рассмотрим, как будет за-
писан RDF граф из примера с пользователями выше. Субъекты user1,
user2 и user3 записываются в специальном тэге rdf:about. Тройки с
каждым из этих субъектов записываются в виде дочерних элементов
этого тэга. Каждый тэг дочернего элемента— это имя предиката, а его
содержимое представляет собой объект. Все определения должны быть
заданы в корневом тэге rdf:RDF. Для подробной информации относи-
тельно синтаксиса RDF в документах XML [см. 28].
<rdf:RDF>
xmlns:usr="http://www.example.org/user-list#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
<usr:user rdf:about="http://www.example.org/user-list#user1">
<usr:id>1</usr:id>
6Как уже говорилось выше, язык XML используется для представления данных
в последовательной форме с тем, чтобы передавать эти данные через Интернет.
Язык RDF использует нотацию XML для передачи описаний Интернет ресурсов по
Сети.
107
<usr:fname>Иван</usr:fname>
<usr:sname>Брусенко</usr:sname>
<usr:age>39</usr:age>
<usr:sex>Мужской</usr:sex>
</usr:user>
<usr:id>2</usr:id>
<usr:fname>Шамиль</usr:fname>
<usr:sname>Галимов</usr:sname>
<usr:sex>Мужской</usr:sex> </usr:user>
<usr:id>3</usr:id>
<usr:fname>Татьяна</usr:fname>
<usr:sname>Волкова</usr:sname>
<usr:sex>Женский</usr:sex>
</usr:user>
</rdf:RDF>
Резюмируя, можно сказать, что RDF графы представляют собой
множества троек вида «субъект, предикат, объект», элементы которых
есть либо ресурсы, обозначаемые через URI, либо литеральные данные
(литералы могут выступать только в качестве объектов). Иногда, в ка-
честве элементов используется ресурс, который не имеет представителя
в Web, так называемый пустой узел (blank node) RDF графа. Пустые
узлы обозначаются в нотацииN3 знаком вопроса. Зачем нужны пустые
узлы? Рассмотрим пример. Пусть известно, что у Шекспира была лю-
бимая, которая жила в Англии и имя которой не сохранилось в веках,
но что любовь к ней вдохновила Шекспира на написание сонета номер
78. Этот факт можно выразить следующим образом:
lit:Mistress1 rdf:type bio:Woman;

bio:LivedIn geo:England .
lit:Sonnet78 lit:hasInspiration lit:Mistress1 .
Но, ввиду того, что мы все-равно не знаем имя любимой Шекс-
пира, нет и необходимости в ее ничего не значащем обозначении
lit:Mistress1. Лучше выразить этот факт следующим образом:
? rdf:type bio:Woman;
bio:livedIn geo:England .
108
lit:Sonnet78 lit:hasInspiration ? .
Тройка с пустым узлом выражает факт существования некото-
рого объекта, для которого тройка выполнима, т.е. в терми-
нах логики, «? rdf:type bio:Woman» эквивалентна высказыванию
∃𝑥 rdf:type(𝑥, bio:Woman). Если необходимо иметь несколько различ-
ных пустых узлов, то можно выделить контекст использования кон-
кретного пустого узла, заключив содержащие его тройки в квадратные
скобки. В этом случае, знак вопроса уже не нужен, он просто опуска-
ется:
[ rdf:type bio:Woman;
bio:livedIn geo:England . ]
Язык запросов SPARQL

Вероятно, у читателя уже сложилось понимание, что описание неко-
торой онтологии на языке RDF представляет собой ориентированный
граф (граф, ребра которого имеют ориентацию, т.е. представляют собой
стрелки), ребра которого помечены предикатами, а вершины— субъек-
том и объектом тройки, которую представляет данное ребро вместе со
своими вершинами. Мы будем использовать термин Хранилище RDF
(RDF Store) для таких графов. В этом смысле, хранилище RDF выгля-
дит как специфичным образом структурированная база данных. По-
лучение данных из реляционной базы обычно производится с помо-
щью запроса , записанного на специальном языке SQL (Structured Query
Language— Структурированный Язык Запросов [5]), запросов к базам
данных. Можно ожидать, что подобный подход практикуется и для
хранилищ RDF. Действительно, в момент написания этой книги, суще-
ствует множество различных диалектов языка запросов к хранилищам
RDF. Консорциум W3 выбрал в качестве стандарта один такой язык—
SPARQL (произносится «спаркл» [см. 17]). SPARQL— это рекурсивный
акроним, который расшифровывается как SPARQL Protocol and RDF
Query Language (SPARQL Протокол и Язык Запросов RDF). Очевидно,
что в названии проводится параллель с аббревиатурой SQL. Обсудим
основные идеи этого языка. В качестве хранилища для запросов будет
использоваться RDF граф с информацией о пользователях, построен-
ный нами в предыдущем разделе.
Основным элементом SPARQL запроса является шаблон тройки
(triple pattern). Шаблон тройки— это тройка, на каких-то местах кото-
рой, вместо субъекта, предиката или объекта, находятся переменные.
109
Переменные обозначаются идентификаторами, которые начинаются со
знака вопроса «?». Например:
?user usr:fname "Иван" .

usr:user2 usr:sname ?name .
?user usr:fname ?name .
Синтаксис записи шаблонов троек очень похож на синтаксис записи
троек в нотации N3
, каждая тройка также заканчивается точкой. Каж-
дый из приведенных выше шаблонов троек можно рассматривать как
вопрос:
Вывести все экземпляры класса user, у которых

usr:fname равно "Иван".
Какое значение свойства usr:sname у экземпляра

usr:user2?
Вывести все значения свойства usr:fname у всех

экземпляров класса user в хранилище.
Для ответа на эти вопросы, анализатор запроса (SPARQL query engine)
произведет поиск в хранилище RDF и выведет все тройки, у которых
на месте переменных могут быть любые значения, а на других местах
те же ресурсы, что заданы в тексте шаблона тройки. Очевидно, что
если шаблон тройки выглядит, как «?sub ?pred ?obj», то в результате,
будут выведены все тройки хранилища.
Хранилище RDF представляет собой граф, поэтому вполне есте-
ственно использовать для поиска не шаблоны троек, а шаблоны гра-
фов. Шаблон графа представляет собой множество шаблонов троек, с
тем свойством, что в переменные с одинаковыми именами должны под-
ставляться одни и те же значения во всех тройках шаблона. В языке
SPARQL, шаблон графа заключается в фигурные скобки. Например,
шаблон графа
{
?user usr:sname ?sname .
}
выводит все фамилии пользователей, у которых имя— это «Иван», а
также имена объектов, у которых usr:fname— это «Иван».
110
Шаблоны графов можно логически комбинировать. Ключевое слово
UNION используется в качестве логического «или». Например, выведем
фамилии тех пользователей, имена которых— это «Иван» или «Татья-
на».
{
{
{?user usr:fname "Иван" .}
UNION
{?user usr:fname "Татьяна" .}
}
{?user usr:sname ?sname .}
}
Запросы на языке SPARQL имеют четыре формы: select, construct,
ask и describe. Рассмотрим каждую из форм подробнее.
Select. Возвращает в качестве результата множество значений перемен-

ных, которые последние принимают на множестве троек, найденных по
запросу. Например, запрос
select ?user ?sname

where
{
?user usr:sname ?sname .
}
выдаст в качестве результата таблицу
user sname
"user1" "Брусенко"
Таблица 3.1: Результаты запроса select.
Обратите внимание, что шаблон графа специфицируется ключевым
словом «where».
Construct. Возвращает в качестве результата граф RDF, состоящий

из всех троек, описываемых данным запросом. Например, запрос
construct {?user usr:sname ?sname}

where
111
{
{?user usr:fname "Иван" .}
UNION
{?user usr:fname "Татьяна" .}
}
даст в результате
usr:user1 usr:sname "Брусенко" .

usr:user3 usr:sname "Волкова" .
Шаблон графа, который будет возвращен в качестве результата, зада-
ется после ключевого слова «construct». Шаблон графа запроса, как
обычное условие запроса, специфицируется ключевым словом «where».
Ask. Эту форму SPARQL запроса можно использовать для того, чтобы
проверить, есть ли в данном хранилище RDF тройки, удовлетворяющие
шаблону графа этого запроса. Если таковые имеются, то возвращается
«да», в противном случае, возвращается «нет». Никакой другой инфор-
мации не возвращается. Например, запрос
ask {?user usr:sname "Путин"}

для хранилища из примера, даст в результате «нет», а запрос
ask {?user usr:sname "Галимов"}

напечатает «да».
Describe. Эта форма SPARQL запроса используется, чтобы получить

описание структуры данного хранилища RDF. Формат возвращаемого
результата определяется анализатором запроса, а не задается пользо-
вателем, как в запросах формы «construct». Можно получить информа-
цию о структуре всего хранилища или о структуре какого-то его под-
графа, это задается в шаблоне графа запроса. Подробно эту форму
запроса мы рассматривать не будем.
Консорциум W3 также определил стандартную XML форму резуль-

татов SPARQL запросов. Формат описан в специальном документе под
названием «Формат XML результатов на SPARQL запросы» [32].
112
RDF Schema
Схема RDF (RDF Schema, RDFS [29]) представляет собой расширение
языка RDF, позволяющее описывать простые онтологии данных, нахо-
дящихся в хранилищах RDF. Также, как схема базы данных описывает
структуру базы данных в виде заголовков таблиц и связей между ними,
схема RDF позволяет описывать структуру RDF хранилища. Структу-
ра описывает в терминах типов и отношений между ними. На самом
деле, как в этом чуть позже убедится читатель, схема RDF позволяет
описывать только классификации с некоторыми дополнительными от-
ношениями. Для того, чтобы описать более сложные виды отношений,
необходимо привлекать более мощные средства, такие как OWL.
Классы. В первой главе мы определили, что классы представляют

собой типизированные множества своих экземпляров. Так как класс—
это тип, то имеется набор свойств, которыми обладают элементы этого
класса. Кроме того, имеется отношения «тип-подтип», которое вводит-
ся, если множество экземпляров одного класса представляет собой под-
множество экземпляров другого класса. Отношение «тип-подтип» на-
зывают также отношением иерархии. Таксономия представляет собой
наиболее простую форму классификации, в которой каждый объект
принадлежит по крайней мере одному классу и типы классов образуют
иерархическое дерево. Рассмотрим, каким образом задаются классы в
RDFS.
В RDFS определен класс всех классов, который обозначается, как
rdfs:Class. Каждый класс задается как экземпляр класса классов
rdfs:Class. Здесь, возможно, у читателя возник вопрос: определяет-
ся ли класс rdfs:Class как экземпляр самого себя? Это действительно
так, класс всех классов определяется следующим образом. Сначала за-
дается класс rdfs:Resource, который обозначает любой RDFS объект.
rdfs:Resource— это класс, т.е. экземпляр класса rdfs:Class. Но, каж-
дая RDFS сущность— это экземпляр класса rdfs:Resource и, поэтому,
rdfs:Class есть экземпляр rdfs:Resource. Экземпляры могут быть
только у классов, которые, в свою очередь, есть экземпляры класса
rdfs:Class. Таким образом, класс всех классов задается рекурсивно, а
именно, как экземпляр самого себя. Допущение, что класс может быть
экземпляром самого себя, выглядит несколько непривычно. В теории
множеств известен парадокс Рассела [см. 20, гл. 2 пар. 4.5], который по-
строен на этом допущении. Конечно, для выражения свойств простой
классификации, использовать классы, которые являются экземпляра-
ми себя, нет необходимости.
113
Как уже говорилось выше, сказать, что данный объект является
экземпляром данного класса, можно с помощью rdf:type. Например,
usr:user rdf:type rdfs:Class .

говорит о том, что «usr:user» является экземпляром класса rdfs:Class
всех классов и, следовательно, классом.
Свойства. В RDFS также существует класс всех свойств, обознача-

емый как rdf:Property. Все свойства являются экземплярами это-
го класса, а сам он, в свою очередь, является экземпляром класса
rdfs:Class.
Для того, что сказать, что значения некоторого свойства являют-
ся экземплярами некоторого класса, т.е. чтобы задать типы свойств,
используется свойство rdfs:range. Выражение
P rdfs:range C
означает, что P— это экземпляр класса rdf:Property, а C— экземпляр
класса rdfs:Class и, что все ресурсы, входящие в качестве объектов
в тройки, предикат которых— это свойство P, являются экземплярами
класса C. В ООП эта ситуация соответствует объявлению типа свойства.
Например, объявление языка C++ «int age;» задает тип int свойства
age, т.е. говорит о том, что все объекты свойства age являются экзем-
плярами класса int.
Если rdfs:range позволяет задать тип значений, которые будет при-
нимать некоторое свойство, то свойство rdfs:domain позволяет задать
класс, чьим атрибутом является данное свойство. Выражение
P rdfs:domain C
говорит о том, что P— это экземпляр класса rdf:Property, а C—
экземпляр класса rdfs:Class и, что все ресурсы, входящие в ка-
честве субъектов в тройки, предикат которых— это свойство P, яв-
ляются экземплярами класса C. Если свойство usr:age являет-
ся атрибутом класса usr:user, то об этом можно сказать так:
usr:age rdfs:domain usr:user. Итак, выражение языка C++
class usr:user{
int usr:age;
};
можно записать на RDFS следующим образом:
114
usr:age rdfs:range int .
usr:age rdfs:domain usr:user .
Свойство rdfs:subClassOf представляет собой аналог наследования
в ООП. Выражение
C1 rdfs:subClassOf C2
означает, что тип C1 является подтипом типа C2, т.е. что каждый эк-
земпляр класса C1 является также и экземпляром класса C2.
Если наследование классов привычно и часто применяет в ООП, то
наследование свойств, на первый взгляд, выглядит непонятно. Но, все
становится на свои места, если рассматривать свойство как множество
троек с одним и тем же предикатом. Все такие тройки можно предста-
вить парами (субъект,объект), здесь мы снова рассматриваем предикат
как бинарное отношение. Если множество пар одного свойства являет-
ся подмножеством пар другого свойства, то можно ввести соотношение
вида «свойство-подсвойство». В RDFS это делается с помощью свойства
rdfs:subPropertyOf. Выражение
P1 rdfs:subPropertyOf P2
говорит о том, что P1 и P2— это экземпляры класса rdf:Property, и что
если есть тройка R1 P1 R2, то обязательно есть и тройка R1 P2 R2. От-
ношение rdfs:subPropertyOf является транзитивным (мы рассмотрим
различные свойства отношений чуть позже).
В RDFS еще определены элементы, позволяющие задавать контейне-

ры (классы, унаследованные от rdfs:Container) и коллекции (класс
rdf:List), которые мы здесь не будем рассматривать. Для подробного
ознакомления со всеми элементами словаря RDF читатель может об-
ратится к официальному описанию RDFS на сайте консорциума W3
[29]. Часто также используются два элемента словаря: rdfs:label и
rdfs:comment. rdfs:label позволяет задавать удобные для человека
имена ресурсов, а rdfs:comment комментировать различные определе-
ния схемы RDF.
На этом мы закончим рассмотрение языка RDF и перейдем к описа-
нию языка OWL, обладающего большей выразительной мощью, нежели
RDF.
115
3.4 Идеология OWL
OWL (Web Ontology Language [16]) представляет собой язык, предна-

значенный для описания онтологий, и разработанный консорциумом
W3 специально для этих целей. OWL— это адаптированная для поиска
версия языка DAML+OIL [23], представляющего собой смесь языков
DAML [33] и OIL [24]. Язык DAML (DARPA Agent Markup Language—
Язык Разметки Агента DARPA) был разработан для DARPA— агент-
ством при Министерстве Обороны США, учрежденным в целях раз-
работки новых технологий для военных нужд. DAML— это язык для
«разметки агентов» сети WWW, т.е. язык описания различных Web
клиентов. Язык OIL (Ontology Inference Layer— Уровень Рассуждения
Онтологии) был разработан европейскими исследователями для описа-
ния Web онтологий. Язык DAML+OIL можно рассматривать как на-
чальную версию OWL.
OWL построен как расширение RDF и RDFS. Это означает, что ба-
зовый синтаксис языка по прежнему представляет собой XML, а основ-
ная конструкция— это тройка языка RDF. В этом контексте, язык OWL
можно рассматривать как расширенный вариант RDFS, позволяющий
не только описывать классы и свойства, но также задавать ограничения
на их использование. На языке дескриптивной логики это означает, что
логика, лежащая в основе OWL, содержит кроме описания отношений
также и аксиомы , задающие соотношения между данными отношения-
ми и различного рода ограничения на последние.
На момент написания книги, разрабатывался стандарт второй вер-
сии OWL. Перевод предварительной рабочей версии краткого введения
в язык OWL 2 можно найти в [18]. Различия между версиями языка
OWL состоят в логиках, на основе которых эти версии реализованы.
Так, первая версия реализована на логике 𝒮ℋ𝒪ℐ𝒩 (𝒟), а вторая— на
логике 𝒮ℛ𝒪ℐ𝒬(𝒟). Хорошее описание различий между этими логика-
ми дано в [35]. Кратко, можно сказать, что 𝒮ℛ𝒪ℐ𝒬(𝒟) представляет
собой расширение 𝒮ℋ𝒪ℐ𝒩 (𝒟), в которое добавлены некоторые новые
ограничения. Например, добавлены такие характеристики свойств, как
ReflexiveObjectProperty или AsymmetricObjectProperty. OWL 2 так-
же имеет новую иерархию диалектов. В OWL 1 имеется три диалекта:
OWL Full, OWL DL и OWL Lite, которые описаны ниже. В OWL 2 та-
кие диалекты называются профилями (profile) и разделение на профили
имеет более сложную структуру, которая основана на вычислительной
сложности алгоритма логического вывода. Опишем ее вкратце:
∙ Профиль EL++ гарантирует, что работа алгоритмов логического
116
вывода, классификации и проверки существования экземпляров
будет проведена за полиномиальное время.
∙ Профиль DL-Lite гарантирует, что реализация процедуры ответа

на вопросы может быть реализована как поиск по реляционной
базе данных.
∙ В профиле OWL-R процедура логического вывода реализуется

как логический поиск по цепным правилам, реализованным как
тройки в хранилище RDF. OWL-R имеет две версии: OWL-R DL
и OWL-R Full.
Подробное описание профилей OWL 2 и их различий можно найти в
документах [26; 25].
Ниже описан язык OWL 1 и далее везде под OWL подразумевается
первая версия этого языка.
Основы языка OWL

Классы
Базовым элементом языка OWL является класс всех классов, опре-
деляемый как owl:Class. Класс owl:Class— это экземпляр класса
rdfs:Class, рассмотренного нами выше. Следовательно, любой OWL
класс должен быть задан как экземпляр класса owl:Class. Например,
если мы хотим определить класс Human (человек), то должны опреде-
лить тройку
Human rdf:type owl:Class
которая в XML синтаксисе будет выглядеть следующим образом:
<owl:Class rdf:ID="Human"/>
В языке OWL также присутствуют два предопределенных класса:
∙ Класс owl:Thing (сущность), который обозначает множество всех
индивидов.
∙ Класс owl:Nothing (ничто), обозначающий пустое множество.

Каждый класс OWL является дочерним классом класса owl:Thing и
родительским классом класса owl:Nothing. Следовательно, дерево на-
следования в OWL образует так называемую полную решетку . Обычно,
достаточно объявить некую сущность экземпляром некоторого класса,
чтобы этот индивид автоматически стал элементом класса owl:Thing.
117
Наследование классов в языке OWL задается с помощью конструк-
ции rdfs:subClassOf, т.е. точно также, как и в языке RDF Schema. Как
и в RDF Schema, тот факт, что один класс является дочерним классом
другого, означает, что все экземпляры дочернего класса являются эк-
земплярами родительского класса.
Свойства
В OWL существует разделение свойств на два класса:
∙ Объектные свойства используются для связывания индивидов

друг с другом. Объектные свойства— это экземпляры класса
owl:ObjectProperty.
∙ Свойства типов данных связывают индивидов с так называемыми
значениями типов данных (data values). Под значениями здесь
подразумеваются RDF-литералы или типы данных, определенные
в XML Schema. Свойства типов данных— это экземпляры класса
owl:DatatypeProperty.
Классы owl:ObjectProperty и owl:DatatypeProperty являются дочер-
ними классами класса rdf:Property. OWL позволяет вводить ограни-
чения на свойства, задавая аксиому, которым эти свойства должны
удовлетворять. Некоторые типы аксиом в OWL поименованы и име-
ются специальные конструкции языка для их определения. К таковым
относятся аксиомы, позволяющие:
∙ Описывать, как свойства соотносятся друг с другом:

owl:equivalentProperty и owl:inverseOf.
∙ Устанавливать глобальные ограничения на мощность:
owl:FunctionalProperty и owl:InverseFunctionalProperty.
∙ Задавать логические характеристики свойств:
owl:SymmetricProperty и owl:TransitiveProperty.
Эти ограничения, также как и ограничения, которые можно нало-
жить на классы, мы рассмотрим подробно в следующем разделе.
Аксиомы классов и свойств в языке OWL

Язык OWL позволяет описывать различные характеристики классов и
свойств, которые обычно задаются как разного рода ограничения на
118
структуру связей между своими экземплярами. Эти ограничения вы-
ражаются в виде предопределенных соотношений, называемых в OWL
аксиомами. Рассмотрим эти соотношения подробнее.
Аксиомы классов
Аксиомы классов определяют правила, на основе которых экземпля-
ры классов связываются друг с другом. Основная аксиома класса— это
объявление его имени как имени класса. Эта аксиома говорит о том,
что класс с таким именем существует. Но этого, конечно, часто быва-
ет мало, чтобы выразить даже простые соотношения иерархии между
классами. Поэтому, в языке языке OWL выделяются еще три аксиомы
классов:
∙ Существующая также и в RDFS, аксиома rdfs:subClassOf, кото-

рая описывает класс как подкласс другого. Как уже говорилось
выше, если класс является подклассом другого, все его экземпля-
ры являются также экземплярами родительского класса.
∙ Аксиома эквивалентности классов owl:equivalentClass, кото-

рая позволяет сказать, что множества экземпляров данных клас-
сов совпадают. Обычно, это просто способ задания синонимов.
Например, можно задать класс с именем ГенеральныйДиректор,
а можно еще сказать о классе ГлаваКомпании. Тогда можно
определить эквивалентность этих классов следующим образом:
ГенеральныйДиректор owl:equivalentClass ГлаваКомпании. Ча-
сто, также аксиому эквивалентности используют как способ име-
нования классов, которые задаются не именем, а какой-нибудь
операцией, например, перечислением своих элементов.
∙ Противоположная по смыслу предыдущей аксиоме эквивалентно-

сти, аксиома owl:disjointWith. Эта аксиома представляет собой
способ сказать, что множества экземпляров классов не имеют об-
щих элементов. Например, можно указать, что класс Мужчина не
имеет общих элементов с классом Женщина.
С классами также связаны так называемые ограничения на атри-

буты (property restrictions), которые формально не являются аксио-
мами классов, но скорее представляют собой еще один способ их опи-
сания. Ограничения описывают анонимные классы, которые задаются
не именами, а представляют собой совокупность экземпляров, удовле-
творяющих данным ограничениям. В OWL существует два вида таких
ограничений:
119
1. Ограничения на значения (value constraints) устанавливаются на
объекты данного свойства, если в качестве субъекта выступает
некоторый конкретный класс. В этом случае, естественно рассмат-
ривать объекты этого свойства как значения атрибутов. Ограни-
чения на значения каким-то образом ограничивают набор инди-
видов, которые могут выступать в качестве таких значений. Мож-
но, например, сказать, что все значения данного свойства долж-
ны быть экземплярами некоторого конкретного класса. В отличии
от rdfs:range, которое устанавливает глобальное ограничение на
значения некоторого свойства, ограничения на значения локальны
в том смысле, что прилагаются к свойствам только, если в каче-
стве их субъекта выступает некоторый конкретный класс. Напри-
мер, для класса СемейнаяПара можно ввести ограничения на свой-
ства Муж и Жена, указав, чтобы первое свойство всегда имело в ка-
честве значений экземпляры класса Мужчина, а второе— Женщина,
если только в качестве субъекта выступает класс СемейнаяПара.
2. Ограничения на мощность (cardinality constraints) задают огра-

ничения на мощность множества значений данного свойства, если
в качестве субъекта выступает некоторый конкретный класс. На-
пример, можно указать, что количество значений свойства Игрок
класса ФутбольнаяКоманда должно равняться числу 11.
Ограничения описываются с помощью класса owl:Restriction и свой-

ства owl:onProperty. Задается экземпляр класса owl:Restriction,
обычно анонимный, так как для описания предметной области он не
нужен и используется только в вспомогательных целях. Класс, для ко-
торого задаются ограничения, объявляется родительским классом для
этого анонимного экземпляра класса owl:Restriction. Например, для
ограничение для класса ФутбольнаяКоманда можно задать так:
:ФутбольнаяКоманда rdf:type owl:Class ;

:ФутбольнаяКоманда rdfs:subClassOf ? ;
? rdf:type owl:Restriction ;
? owl:onProperty :Игрок ;
? owl:cardinality 11 .
В данном примере мы использовали встроенное в OWL ограничение
owl:cardinality, позволяющее задавать количество значений некото-
рого свойства, если в качестве субъекта выступает некоторый конкрет-
ный класс. Мы используем конструкцию :ФутбольнаяКоманда с двое-
точием, чтобы отличить идентификатор класса от обычной строки,
120
которая используется в языке OWL в качестве значений типов дан-
ных. Конструкция :Id эквивалентна конструкции namespace:Id, толь-
ко в качестве пространства имен в первом случае используется так
называемое неименованное пространство имен. Идентификаторы, ко-
торые объявлены в таком пространстве имен, также отличаются от
идентификаторов в других пространствах, но в качестве имени про-
странства используется пустая строка. Итак, в конструкции выше объ-
явлен класс :ФутбольнаяКоманда, который является подклассом ано-
нимного класса, являющегося экземпляром класса owl:Restriction. В
этом случае, анонимный класс может выступать субъектом предикатов
owl:onProperty и owl:cardinality.
Приведем описание встроенных в язык OWL ограничений. Эти огра-
ничения представляют собой свойства, который описывают характери-
стики других свойств, как это видно из примера выше.
Ограничения на значения:
∙ Ограничение owl:allValuesFrom используется для того, чтобы
указать, что все значения свойства представляют экземпляры од-
ного класса, если только в качестве субъекта этого свойства вы-
ступает данный класс. Например, для класса Персона мы вводим
свойство имеетРодителя и указываем, что его значения на этом
классе— это экземпляры класса Человек. В языках ООП можно
задать члены классов, указывая их тип, данное ограничение пред-
ставляет собой аналог такого задания. В классе Персона мы мог-
ли бы задать свойство имеетРодителя с типом Человек. В логике,
аналогом owl:allValuesFrom служит квантор всеобщности.
∙ Ограничение owl:someValuesFrom представляет собой аналог

квантора существования в логике. Если это ограничение накла-
дывается на некоторое свойство какого-то класса, то это означает,
что могут быть экземпляры класса—значения, которые связаны с
некоторым экземпляром класса субъекта данным свойством. На-
пример, можно ввести класс Учитель и установить ограничение
owl:someValuesFrom на свойство имеетРодителя класса Персона,
указав, что некоторая персона может иметь в качестве родите-
ля учителя (конечно, в предположении, что некоторые учителя
имеют детей). В логике для тех же целей используется квантор
существования.
∙ Ограничение owl:hasValue используется, чтобы указать, что дан-

ное свойство имеет по крайней мере одно выделенное значение.
121
Например, можно задать ограничение owl:hasValue на свойство
имеетРодителя, указав, что в качестве значения должен быть ин-
дивид под именем Иванов. Это ограничение задает класс всех ин-
дивидов, у которых имеется родитель по фамилии Иванов.
Ограничения на мощность:
∙ Ограничение owl:maxCardinality задает максимальное количе-
ство значения данного свойства, если в качестве его субъекта вы-
ступает выделенный класс. Например, можно задать ограничение
на свойство имеетРодителя класса Персона, указав, что количе-
ство значений этого свойства не может быть более двух.
∙ Ограничение owl:minCardinality используется для задания ми-

нимального количества значений данного свойства, у которого в
качестве субъекта выступает некоторый класс. Точно также, как и
в предыдущем примере, минимальное количество значений свой-
ства имеетРодителя класса Персона можно задать равным двум.
∙ Ограничение owl:cardinality позволяет явно задать количе-

ство значений некоторого свойства некоторого класса. Напри-
мер, можно было бы заменить ограничения owl:maxCardinality
и owl:minCardinality свойства имеетРодителя класса Персона на
одно ограничение owl:cardinality, устанавливающее количество
значений данного свойства равным двум.
Во качестве класса значений свойств ограничений на мощность высту-

пает встроенный в XML класс nonNegativeInteger.
Аксиомы свойств
Характеристики свойств делятся в языке OWL на три группы:
∙ Характеристики, выражающие отношения данного свой-

ства с другими. К ним относятся owl:equivalentProperty и
owl:inverseOf.
∙ Глобальные ограничения на мощность свойств. В чис-
ло таких ограничений входят owl:FunctionalProperty и
owl:InverseFunctionalProperty.
∙ Логические характеристики свойств, такие как
owl:TransitiveProperty и owl:SymmetricProperty.
122
Рассмотрим каждую характеристику более подробно.
owl:equivalentProperty. Эта характеристика используется, чтобы вы-

разить тот факт, что два свойства имеют одно и то же множество пар
индивидов, которые они связывают. В OWL различают эквивалент-
ность (equivalence) иравенство (equality) свойств. Эквивалентность
означает, что данные свойства совпадают по содержанию, т.е. по па-
рам индивидов, которые они связывают. Равенство выражается посред-
ством свойства owl:sameAs. Это свойство связывает между собой толь-
ко индивидов, поэтому если оно прилагается к свойствам, то эти свой-
ства также должны рассматриваться как индивиды. Такое возможно
только в OWL Full, где не проводится различия между классами и ин-
дивидами, т.е. где класс может рассматриваться также и как экземпляр
себя.
owl:inverseOf. Как ранее неоднократно указывалось, свойства— это

бинарные отношения, т.е. множество пар индивидов. Эти пары упоря-
дочены, первый элемент пары называется субъектом, а второй— объ-
ектом. Если свойство характеризуется как обратное (inverse) другого
свойства, это означает, что характеризуемое свойство состоит из того
же множества пар, но в которых субъект и объект поменялись места-
ми. Например, если имеется свойство имеетРодителя, то с помощью
конструкции имеетРебенка owl:inverseOf имеетРодителя можно вве-
сти обратное ему свойство имеетРебенка.
owl:FunctionalProperty. Функцию также можно рассматривать как

множество пар (бинарное отношение), первые элементы которых од-
нозначно определяют вторые. Важной характеристикой функции как
бинарного отношения является то, что если какой-то индивид появился
в какой-то паре на первом месте, то он уже не может появиться ни в
какой другой паре на первом месте. В противном случае, это противоре-
чило бы здравому смыслу, ведь каждому элементу области определения
должен сопоставляться единственный элемент области значений. В ка-
честве примера функционального отношения можно привести свойство
имеетМужа, которое сопоставляет экземплярам класса Женщина экзем-
пляры класса Мужчина. Предполагается, что у женщины не может быть
более одного мужа одновременно, поэтому это свойство полезно сделать
функциональным.
owl:InverseFunctionalProperty. Свойство аналогично предыдущему,

только обращено не к первым, а ко вторым элементам пар отноше-
ния. Если некоторый индивид появился в какой-нибудь паре в каче-
123
стве второго элемента, то он уже не может появиться в этой роли
ни в какой другой паре отношения. Рассмотрим, например, свойство
являетсяБиологическойМатерью, в качестве субъектов которого высту-
пают экземпляры класса Женщина, а в качестве значений— экземпляры
класса Человек. Это свойство полезно сделать обратно-функциональ-
ным, так как любой человек не может иметь более одной биологической
матери.
owl:TransitiveProperty. Транзитивность означает, что если данному

отношению принадлежат пары (𝑥, 𝑦) и (𝑦, 𝑧), то во множестве пар дан-
ного отношения обязательно должна быть также и пара (𝑥, 𝑧). Здесь па-
ра (𝑥, 𝑧) образует «транзитом» через элемент 𝑦 . Примером транзитив-
ного отношения является любое отношение иерархии. Пусть, например,
имеется класс Область, элементами которого являются области плоско-
сти. Некоторые области содержаться в других, что можно выразить от-
ношением подобласть. Очевидно, что это отношение транзитивно, т.к.
если область является подобластью другой области, то она является
также и подобластью любой содержащей области, содержащей послед-
нюю.
owl:SymmetricProperty. Симметричное отношение характеризует сле-

дующее свойство. Если во множестве пар отношения имеется пара
(𝑥, 𝑦), то обязательно должна быть и пара (𝑦, 𝑥). В этом смысле, от-
ношение состоит только из симметричных пар, что и определяет его
название. В качестве примера симметричного отношения можно при-
вести отношение друг между экземплярами класса Человек. Если один
человек является другому другом, то верно и обратное.
Диалекты языка OWL

Существует три версии языка OWL:
OWL Full. Диалект OWL Full, фактически, представляет собой язык

RDF Schema с расширенным синтаксисом. В OWL Full класс owl:Class
никак не отличается от rdfs:Class, в других диалектах OWL не каж-
дый RDFS класс является OWL классом. Как и в RDFS, в OWL Full
не проводится различий между классами и индивидами, т.е. класс мо-
жет рассматриваться и как совокупность индивидов и как индивид.
Например, в OWL Full Ту-154 может быть именем класса, т.е. обо-
значать множество самолетов, но может также и быть экземпляром
класса ТипСамолета. В OWL Full все индивиды рассматриваются как
124
элементы одного фиксированного множества ресурсов (owl:Thing эк-
вивалентно rdfs:Resource). Поэтому, нельзя провести различия меж-
ду объектными свойствами (owl:ObjectProperty) и свойствами типом
данных (owl:DatatypeProperty). Отсутствие каких-либо специальных
ограничений на соотношения между элементами в языке не позволяет
в общем случае гарантировать, что процедура логического вывода по
онтологиям, реализованным на этом языке, закончит свое выполнение
в разумные сроки (или вообще закончит).
OWL DL. Данный диалект реализует возможности описания онтоло-

гий на основе рассмотренных выше Дескриптивных Логик. Точнее, ре-
ализуется одна из таких логик— так называемая 𝒮ℋ𝒪ℐ𝒩 (𝒟). Проце-
дура логического вывода здесь уже вычислима, т.е. всегда заканчивает
свою работу в разумное время. OWL DL включает в себя все языковые
конструкции OWL вместе с различными ограничениями. Перечислим
наиболее важные их них:
∙ OWL DL различает классы, типы данных, свойства типов данных

и объектные свойства и индивиды. Это значит, что класс не может
быть одновременно индивидом.
∙ Как уже сказано выше, OWL DL различает объектные

свойства и свойства типов данных. Это означает, что ха-
рактеристики owl:inverseOf, owl:InverseFunctionalProperty,
owl:TransitiveProperty и owl:SymmetricProperty не могут при-
меняться к свойствам типов данных.
∙ OWL DL не разрешает применять ограничения мощности к тран-

зитивным свойствам и их обращениям.
∙ Существует существенное ограничение на использование элемен-

тов словаря языка RDF Schema в OWL DL. Фактически, в OWL
DL запрещено использование почти всех элементов RDFS.
OWL Lite. Диалект OWL Lite разработан, чтобы проектировать про-

стые таксономии, в которых можно также объявлять некоторые до-
полнительные простые соотношения. В OWL Lite реализована логика
𝒮ℋℐℱ(𝒟). OWL Lite сохраняет все ограничения диалекта OWL DL, но
также добавляет и свои. Перечислим некоторые из таких ограничений:
∙ В OWL Lite запрещено использование таких ограничений, как

owl:hasValue, owl:disjointWith и некоторых других.
125
∙ OWL Lite требует, чтобы субъект предиката
owl:equivalentClass был именем класса, а объект этого
предиката был, либо именем класса, либо анонимным классом,
образованным ограничениями. Это же требуется и для предиката
rdfs:subClassOf.
∙ Объекты предикатов owl:allValuesFrom и owl:someValuesFrom
должны быть именами классов или типов данных.
∙ Объекты предиката rdf:type должны быть именами классов или

анонимным классом, образованным ограничениями.
∙ Объекты предиката rdfs:domain должны быть именами классов,

а объекты предиката rdfs:range— именами классов или типов
данных.
Подробное описание различий между диалектами OWL заинтересо-

ванный читатель может найти в официальном описании языка OWL на
сайте консорциума W3 [см. 3, раздел 8].
3.5 OWL редактор Protege
Protege представляет собой, вероятно, наиболее популярный на настоя-

щий момент редактор OWL и RDF. Редактор доступен для бесплатного
скачивания с сайта программы [12]. Программа распространяется под
так называемой Mozilla Public License (Открытая Лицензия Mozilla),
которая разрешает использовать программу бесплатно даже в коммер-
ческих разработках. Программа реализована на языке Java и поэтому
требуется предварительная установка Java машины. Обычно, Java ма-
шина распространяется вместе с Protege как часть системы ее установ-
ки на компьютер пользователя. Protege представляет собой удобный
редактор для создания OWL онтологий и именно в этом качестве мы
его рассмотрим. Итак, приступим к описанию возможностей данного
редактора. Рассматриваемая здесь версия программы имеет номер 3.4
и базируется на первой версии языка OWL. Имеется также бета-версия
Protege 4.0, которая поддерживает OWL 2.
Создание проекта
Онтологии в Protege создаются в виде так называемых проектов
. Про-
ект— это конфигурационные данные, прежде всего, имя OWL файла, в
126
котором хранится редактируемая онтология. Конфигурационные дан-
ные также хранят различные установки редактирования, связанные с
данным проектом. При запуске редактора Protege предлагает пользова-
телю прейти к редакции существующих проектов, либо создать новый
проект. Мы создадим новый проект.
Создание проекта начинается с выбора типа хранилища, в котором
будет содержаться онтология. Мы выбираем тип «OWL/RDF Files» (см.
рисунок 3.3).
Рис. 3.3: Создание проекта Protege: выбор типа хранилища.

Нажимаем кнопку «Next» (далее) и переходим к шагу выбора имени
создаваемой онтологии. Онтологии в OWL должны иметь уникальные
имена в Web, поэтому имя онтологии представляет собой Web ссылку.
Выбираем то имя, которое по умолчанию предлагает редактор Protege:
http://www.owl-ontologies.com/Ontology1237978552.owl. В данном слу-
чае, 1237978552— это сгенерированный редактором числовой иденти-
фикатор нашей онтологии (см. рисунок 3.4).
Переходим к следующему шагу. Здесь предлагается выбрать диа-
лект OWL, на котором будет реализована наша онтология. Также, мож-
но выбрать и реализацию онтологии на RDF Schema. Мы выбираем
предлагаемый по умолчанию диалект OWL DL и нажимаем кнопку
«Finish» заканчивая создание проекта (см. рисунок 3.5).
127
Рис. 3.4: Создание проекта Protege: выбор имени онтологии.
Редактирование онтологии
После того, как создание проекта завершено, открывается главное окно
программы. Окно программы содержит в своей верхней части пять за-
кладок, позволяющие разделить функционально различные действия
по редактированию друг от друга. Перечислим эти закладки:
∙ Метаданные. Данная закладка позволяет редактировать метадан-

ные об онтологии. Это те данные, которые не относятся непосред-
ственно к данным, описываемым в самой онтологии, но харак-
теризуют саму онтологию. Здесь можно изменить имя онтоло-
гии, добавить псевдоним (prefix) имени онтологии, которые может
использоваться, как другими использующими данную онтологию
программами, так и внутри самой онтологии в качестве короткого
имени— так называемого префикса, позволяющего различать име-
на, определенные в данной онтологии, от имен других онтологий.
Также можно написать комментарии к редактируемой онтологии.
∙ Вкладка «Классы OWL» (OWL Classes) позволяет создавать но-

вые классы. Все создаваемые классы являются подклассами клас-
са owl:Thing. Классы можно создавать не только по именам, но
также и с помощью описанных выше логических конструкторов,
128
Рис. 3.5: Создание проекта Protege: выбор диалекта OWL.
таких как конъюнкция, дизъюнкция и других. Также можно на-

лагать описанные выше ограничения на значения и мощность
свойств классов.
∙ Вкладка «Свойства» (Properties) содержит различную функцио-

нальность по редактированию свойств. Можно создавать объект-
ные свойства и свойства типов данных. Для создаваемого свойства
можно выбрать его domain и range, а также установить характе-
ристики свойства, такие как функциональность, обратную функ-
циональность, симметричность и транзитивность. Особым обра-
зом выбирается характеристика обратного свойства, так как для
этой характеристики необходимо свойство, обратным к которому
является данное свойство.
∙ Вкладка «Индивиды» (Individuals) позволяет задавать экземпля-

ры классов. Вкладка показывает экземпляры двух видов: экзем-
пляры, которые введены пользователем (asserted) и экземпляры,
которые введены системой на основании правил, заложенных в
онтологии (inferred). Например, если некоторое свойство являет-
ся обратным к другому и вводится пара индивидов, связанных
этим свойством, то система автоматически введет соответствую-
129
щую пару для обратного свойства.
∙ Вкладка «Формы» (Forms) позволяет автоматически генериро-

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

тируемой онтологии и задавать к онтологии SPARQL запросы. При
выборе пункта главного меню «Вывод» (Reasoning) можно провести
следующие операции:
∙ Произвести проверку логической совместимости онтологии

(Check consistency).
∙ Произвести классификацию индивидов онтологии, т.е. построить

таксономию (Classify taxonomy).
∙ Вычислить новые классы с помощью продекларированных кон-

структоров классов (Compute inferred types).
∙ Задать к онтологии запрос на языке SPARQL.
∙ Сменить программы логического вывода, с помощью которой про-

изводятся описанные выше операции. Версия 3.4 предлагает две
таких программы: DIG Reasoner и Pellet 1.5.2.
Кроме описанных операций редактор Protege позволяет делать еще

многие вещи, которые здесь, по методологическим соображениям, опи-
саны не будут. Заинтересованный читатель может обратиться к доку-
ментации, описывающей работу с редактором, размещенной на сайте
программы ([12]).
Иллюстративный пример
Построим простейшую онтологию родственных отношений. В каче-
стве примера, рассмотрим созданную для учебных целей онтологию
«family.swrl», которую можно загрузить в виде OWL файла с сайта
библиотеки онтологий программы Protege [27]. Этот пример также со-
держит демонстрацию возможностей языка SWLR (Semantic Web Rule
130
Language— Языка Правил Semantic Web [31]). Язык SWLR использует-
ся для задания так называемых правил
онтологий OWL, позволяющих
добавить действия, которые будут выполняться при добавлении новых
фактов в онтологию. Например, можно добавить правило, которое го-
ворит системе, реализующей онтологию, автоматически добавлять пару
(x,y) в отношение иметьДочь, если только некоторая персона x имеет
ребенка женского пола. Выглядит такое правило так:
Person(?x) and hasChild(?x,?y)

and Woman(?y)
==> hasDaughter(?x,?y)
В онтологии «family.swrl» правила вводятся для того, чтобы запол-
нить данную онтологию различным отношениями на основании вве-
денных пользователем базовых отношений. В качестве таких базовых
отношений выступают всего два отношения: hasChild (имеет ребенка)
и hasSex (пол)7 . На основе этих отношений и имеющихся в онтологии
«family.swrl» правил вводятся все остальные свойства и экземпляры
классов онтологии.
Рассмотрим, например, правило, на основе которого вводится свой-
ство hasSibling (иметь брата или сестру):
Person(?y) and hasChild(?y,?x)

and hasChild(?y,?z)
and differentFrom(?x,?z)
==> hasSibling(?x,?z)
Это правило говорит о том, что если некая персона ?y имеет ребенка
?x и эта же персона ?y имеет ребенка ?z, который отличен от ?x, то
персона ?z является братом или сестрой персоны ?x.
Теперь, можно ввести отношение hasBrother на основании отноше-
ния hasSibling и отношения hasSex:
Person(?x) and hasSibling(?x,?y)

and Man(?y)
==> hasBrother(?x,?y)
7Отношение hasSex заполняется при определении экземпляров классов Man
(мужчина) и Woman (женщина), которые являются подклассами класса Person. Каж-
дый экземпляр класса Man должен иметь свойство «hasSex Male», а каждый экзем-
пляр класса Woman, соответственно, свойство «hasSex Female». Таким образом, если
вводится экземпляр x класса Man, то соответственно, вводится и экземпляр отноше-
ния «x hasSex Male».
131
Правило гласит: если некая персона ?x находится в родственной свя-
зи с персоной ?y, которая является мужчиной, то персона ?x имеет в
качестве брата мужчину ?y.
Подобными правилами заполняются также и остальные отношения
онтологии. Мы не будем приводить их все, рекомендуем заинтересован-
ному читателю открыть онтологию «family.swrl» в редакторе Protege и
самостоятельно просмотреть содержимое закладки правил главного ок-
на редактора. Перейдем лучше к описанию типов и свойств онтологии.
Иерархия классов онтологии Family

На рисунке 3.6 приведена иерархия классов онтологии Family.
Иерархия классов в Protege выводится в окне «Subclass Explorer»
вкладки «Классы». Как видно из рисунка, на вершине иерархии на-
ходится класс owl:Thing, который, о чем мы уже говорили выше,
всегда является базовым классом для любого элемента онтологии. У
класса owl:Thing есть два подкласса: Gender (пол) Person (персона).
Класс Gender образован как перечисление экземпляров Male (муж-
ской) Female (женский). Также, присутствуют классы Man (мужчина)
и Woman (женщина), которые являются подклассами класса Person. В
свою очередь, класс Person представляет собой дизъюнкцию классов
Man и Woman. Этот факт выражает программой Protege в правом окне
вкладки «Классы», которое называет «Редактор Классов» (см. рисунок
3.7).
Остальные классы представляют собой перечисление многочислен-
ных родственных связей, над которым также образованы классы. На-
пример, класс Sibling (потомство одних родителей) имеет в качестве
подклассов классы Brother (брат) и Sister (сестра)8 . Мы не будем по-
дробно останавливаться на этой иерархии. Интересной особенностью
данной онтологии представляется то, что пол человека вводится так-
же и как экземпляр класса Gender: Male и Female. Это позволяет явно
обозначать пол того или иного класса посредством отношения hasSex
8Введение типов Brother и Sister довольно необычно для OWL. Обычный
подход состоит в том, чтобы определить отношения hasBrother и hasSister,
которые связывают экземпляры класса Person с экземплярами классов Man и
Woman, соответственно. Это и сделано в данной онтологии. Но, с помощью пра-
вил можно сделать экземпляры класса Man, входящие как объекты в свой-
ство hasBrother, экземплярами класса Brother. Это правило могло бы соот-
ветствовать следующему высказыванию: «если некий экземпляр класса Man вхо-
дит в качестве объекта в свойство hasBrother, то этот экземпляр является
также экземпляром класса Brother». На языке SWLR это выглядело бы так:
Man(?y) and hasBrother(?x,?y) ==> Brother(?y). В текущей версии онтологии
«family.swrl» эти отношения не введены, но вполне могут иметься.
132
Рис. 3.6: Иерархия классов онтологии Family.
(иметь пол). В онтологии также вводятся ограничения на мощность для

родственников. Например, класс Brother имеет ограничение на мощ-
ность owl:minCardinality свойства hasSibling (иметь брата или сест-
ру): человек называется братом только в том случае, если у него есть
хотя бы один брат или сестра.
Свойства онтологии Family
133
Рис. 3.7: Определения классов Gender и Person.
В онтологии Family присутствуют только объектные свойства, свой-

ства типов данных используются только как вспомогательные эле-
менты для правил языка SWLR. Значимые для нас объектные свой-
ства приведены на рисунке 3.8. Из наиболее интересных свойств сто-
ит упомянуть обратные друг другу свойства hasChild (иметь ребенка)
hasParent (иметь родителя). Свойство hasSibling (иметь брата или
сестру) является симметричным. Все три перечисленных свойства име-
ют подсвойства. Так, например, свойство hasParent имеет два подст-
войства: hasFather (иметь отца) и hasMother (иметь мать). Очень ин-
тересный пример— свойство hasConsort (иметь супруга). Это свойство
одновременно функциональное и симметричное. Действительно, в дан-
ный момент времени возможно иметь только одного супруга (функци-
ональность) и супруг также является супругом данной персоны (сим-
метричность). В редакторе Protege характеристики свойств редакти-
руются в правом окне вкладки «Свойства». На рисунке 3.9 показаны
характеристики свойства hasConsort.
Индивиды и формы онтологии Family

Как уже говорилось выше, формы и индивиды (которые выступа-
ют как экземпляры классов) можно редактировать на соответствую-
134
Рис. 3.8: Иерархия свойств онтологии Family.
Рис. 3.9: Характеристики свойства hasConsort.
щих вкладках. В онтологии Family введены уже упоминавшиеся выше

два экземпляра класса Gender: Male и Female. Также, введены десять
экземпляров класса Man и десять экземпляров класса Woman. Эти эк-
земпляры поименованы, соответственно, как Mn и Fn, где n— это номер
экземпляра. Вкладка индивидов разделена на три окна: «Просмотор-
щик классов», «Просмоторщик экземпляров» и «Редактор индивида».
На рисунке 3.10 приведен вид окна «Просмоторщик экземпляров» и
вид окна «Редактор индивида» для экземпляра M02. Из рисунка вид-
135
Рис. 3.10: Редактор экземпляра M02.
но, что экземпляр M02— это мужчина (свойство hasSex установлено в

Male), имеет в качестве супруги экземпляр F04 (свойство hasConsort)
и имеет в качестве родителей экземпляры M01 и F01. Также отмечены
дети экземпляра, это: F05, M03 и M05. Подобные построения сделаны
и для других экземпляров. Особо отметим, что форма ввода каждо-
го экземпляра генерируется автоматически на основании соотношений,
введенных в данной онтологии для класса, экземпляром которого яв-
ляется данный индивид.
136
3.6 Реализации хранилищ онтологий на
основе OWL и RDF
В этом разделе мы рассмотрим наиболее известные реализации храни-

лищ онтологий, предоставляющие интерфейс на языках OWL и RDF.
Следует заметить, что в сравнении с реляционными базами данных,
хранилище онтологий на основе RDF троек, если так можно выразить-
ся, страдают невысокой производительностью. Как неоднократно го-
ворилось выше, база знаний на основе RDF троек представляет собой
граф, узлами которого служат субъекты и объекты RDF предикатов,
а ребрами— сами RDF предикаты. Быстрый поиск по этому графу ре-
ализовать сложно. Поэтому, при реализации хранилищ основное вни-
мание уделяется скорости обработки запросов к данному хранилищу.
Ниже дается список бесплатно предоставляемых программных систем
с открытыми исходными кодами, которые заинтересованный читатель
может использовать для своих нужд, просто загрузив реализацию си-
стемы с соответствующего сайта. Этот список не претендует на полноту,
но просто представляет собой перечисление заинтересовавших автора
программных реализаций хранилищ RDF троек.
OWLIM
Хранилище онтологий OWLIM [8], как декларируется его разработчи-
ками, представляет собой быстрейший на сегодняшний день RDF и
OWL сервер. Система разработана на языке Java. OWLIM поставляется
в нескольких версиях, возможности каждой из которых специальным
образом подогнаны для целевых манипуляций. Наиболее известные вер-
сии— это:
∙ SwiftOWLIM. В данной версии, логический вывод и обработка за-

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

на жестком диске. Это, с одной стороны, ухудшает быстродей-
ствие системы, но с другой стороны, дает возможность разме-
щать на компьютерах со стандартной конфигурацией больший
базы знаний.
137
База знаний OWLIM используется в проекте Sesame [10], разраба-
тываемом компанией Aduna. Sesame представляет собой полноценный
Web-сервер, написанный на языке Java, и предоставляющий возмож-
ности по распределенному хранению знаний в формате RDF. Сервер
Sesame доступен для бесплатного скачивания.
Bigdata
Bigdata [6] представляет собой разработанное для многоцелевого ис-
пользования хранилище структурированных данных. Данные хранят-
ся в формате так называемых B-деревьев (B+Trees). При разработке,
в систему были заложены возможности хранить данные на кластерах.
Новые устройства для хранения могут быть динамически добавлены в
систему во время ее работы. Кроме того, система поддерживает идео-
логию map/reduce.
Для Bigdata написано также хранилище RDF троек, реализован-
ное поверх основной базы. Сервер хранилища поддерживает обработку
запросов на языке SPARQL, а также позволяет сохранять данные меж-
ду перезапусками системы. В программной системе также реализована
поддержка RDFS и ограниченного логического вывода OWL.
Сервер Bigdata поставляется с открытыми исходными кодами.
Jena TDB
TDB представляет собой хранилище RDF троек, разработанное в каче-
стве специально предназначенного для этих целей уровня в программ-
ной системе Jena [7]. Jena представляет собой сервер обработки запро-
сов на языке SPARQL, сохраняющий данные в виде RDF троек. В си-
стеме имеются несколько уровней, предназначенных для осуществле-
ния тех или иных целей. Уровень TDB предназначен для сохранения
троек в постоянной памяти.
Программная система Jena реализована на языке Java и поставля-
ется с открытыми исходными кодами. Имеется возможность сохранять
данные непосредственно на диске и в известных реализациях реляци-
онных баз данных.
Имеется также новая реализация хранилища для системы Jena, но-
сящая имя SDB. Хранилище SDB может сохранять данные большего
объема, чем предыдущая версия и поддерживает больше форматов баз
данных.
138
Mulgara
Mulgara [11] представляет собой расширяемую базу RDF троек. Систе-
ма написана на языке Java и предоставляет с открытыми исходными
кодами. Mulgara предоставляет возможность задания запросов на язы-
ке SPARQL. Также, в системе реализованы взаимодействие с обсуждав-
шейся выше программной системой Jena и много других возможностей.
Например, система предоставляет сервис обработки правил SWLR.
1. Обзор языка SGML на сайте W3.

http://www.w3.org/MarkUp/SGML/.
2. Описание концепций языка RDF на сайте W3.
http://www.w3.org/TR/rdf-concepts/.
3. Описание языка OWL на сайте W3. http://www.w3.org/TR/owl-
ref/.
4. Описание языка XML на сайте W3. http://www.w3.org/XML/.
5. Б. Форта. Освой самостоятельно язык запросов SQL / Пер. с англ.—
3-е изд. Москва: Диалектика, 2005.
6. Сайт Bigdata. http://www.bigdata.com/blog/.
7. Сайт Jena. http://jena.sourceforge.net/.
8. Сайт OWLIM Semantic Repository.
http://www.ontotext.com/owlim/.
9. Сайт консорциума World Wide Web. http://www.w3.org/.
10. Сайт проекта Sesame. http://www.openrdf.org/.
11. Сайт Mulgara. http://www.mulgara.org/.
12. Сайт редактора онтологий OWL Protege.
http://protege.stanford.edu/.
13. Спецификация нотации N-Triple на сайте консорциума W3.
http://www.w3.org/2001/sw/RDFCore/ntriples/.
14. Спецификация нотации Turtle на сайте консорциума W3.
http://www.w3.org/TeamSubmission/turtle/.
139
15. Спецификация нотации N3 на сайте консорциума W3.
http://www.w3.org/DesignIssues/Notation3.html.
16. Страница на сайте консорциума W3, посвященная OWL.

http://www.w3.org/2004/OWL/.
17. Страница на сайте консорциума W3, посвященная языку SPARQL.

http://www.w3.org/2001/sw/DataAccess/.
18. C. Щербак. Язык Web-онтологий OWL 2: начальное руководство.

http://shcherbak.net/translations/ru_owl2primer_shcherbak_net.html.
19. Страница Semantic Web на сайте консорциума World Wide Web.

http://www.w3.org/2001/sw/.
20. Р. Курант, Г. Роббинс. Что такое математика? 3-e издание, испр. и

доп.— Москва, 2001.
21. M. Minsky. A framework for representing knowledge. In J. Haugeland,

editor, Mind Design. The MIT Press, 1981.
22. M. Schmidt-Schauss, G. Smolka. Attributive concept descriptions with

complements. Artificial Intelligence 48:1-26, 1991.
23. DAML+OIL (March 2001) Reference Description.

http://www.w3.org/TR/daml+oil-reference.
24. Description of OIL. http://www.ontoknowledge.org/oil/.
25. OWL 2 Web Ontology Language: Profiles.

http://www.w3.org/TR/2008/WD-owl2-profiles-20080411.
26. OWL 2 Web Ontology Language: Structural Specification and

Functional-Style Syntax. http://www.w3.org/TR/2008/WD-owl2-
syntax-20080411.
27. Protege Ontology Library. http://protegewiki.stanford.edu/

index.php/Protege_Ontology_Library.
28. RDF/XML Syntax Specification (Revised).

http://www.w3.org/TR/rdf-syntax-grammar.
29. RDF Vocabulary Description Language 1.0: RDF Schema.

http://www.w3.org/TR/rdf-schema/.
140
30. D. Allemang, J. Handler. Semantic Web for the Working Ontologist:
Effective Modeling in RDF, RDFS and OWL. Morgan Kaufmann,
2008.
31. A Semantic Web Rule Language: Combining OWL and RuleML.

http://www.w3.org/Submission/SWRL/.
32. SPARQL Query Results XML Format. http://www.w3.org/TR/rdf-

sparql-XMLres/.
33. The DARPA Agent Markup Language Homepage.

http://www.daml.org/.
34. The Description Logic Handbook: Theory, implementation, and

applications. Edited by F. Baader, D. Calvanese, D. McGuiness,
D. Nardi, P. Patel-Schneider. Cambridge University Press, 2003.
35. I. Horrocks, O. Kutz, U. Sattler. The Even More Irresistible SROIQ.

Proc. of the 10th Int. Conf. on Principles of Knowledge Representation
and Reasoning (KR2006). p.57—67, 2006.
36. M. Quillian. Word concepts: A theory and simulation of some basic

capabilities. Behavioral Science, 12:410–430, 1967.
37. Uniform Resource Identifier (URI): Generic Syntax.

http://tools.ietf.org/html/rfc3986.
38. Uniform Resource Locators (URL). http://tools.ietf.org/html/rfc1738.
39. URN Syntax. http://tools.ietf.org/html/rfc2141.
141
4 Ontolingua— Web-сервер
библиотек онтологий
4.1 Концепция «разделяемых знаний»
Концепция «разделяемых знаний», предложенная Томасом Грубером в

его статьях [17; 15], лежит в основе системы Ontolingua. Эта концепция
уже обсуждалась нами в первой главе, напомним читателю ее содержа-
ние.
Решаемая Грубером задача состояла в том, чтобы выработать меха-
низмы взаимодействия программных систем баз знаний друг с другом.
В рамках решения этой проблемы был преложен следующий подход:
∙ Выделить в системе управления знаниями уровень так называемо-

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

другим программам управления знаниями. Причем, такое описа-
ние должно быть понятно, как человеку, так и машине, и потому,
выдается в двух видах:
142
1. Канонической форме, представляющей собой описание зна-
ния на обычном языке логики предикатов.
2. В форме онтологии , как ее представлял в тот момент Гру-
термов
бер, т.е. в виде набора описаний (классов, отношений,
определений
констант и т.д.) и , связывающих эти термы друг
с другом.
∙ Построить, на основе выделенных описаний, библиотеки онтоло-

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

он сейчас используется в компьютерной науке, впервые был сформули-
рован Грубером именно в связи с описываемой проблемой.
Задача построения описания знания является довольно специфиче-
ской. Грубер даже выделил для этой задачи отдельный термин— «спе-
цификация концептуализации». Здесь под «концептуализацией» пони-
мается «абстрактный, упрощенный взгляд на мир, который использу-
ется людьми для осуществления некоторой цели» [16]. Это подробно
обсуждалось в первой главе. Особенность задачи концептуализации за-
ключается в том, что для обмена знаниями между программными си-
стемами необходимо явно специфицировать их концептуализацию, т.е.
построить описание этих знаний, причем в достаточной степени фор-
мальное, чтобы его понимали другие системы. Результат такой специ-
фикации был назван Грубером термином «онтология»1 .
В рамках решения проблемы разделяемых знаний был использован
язык KIF (Knowledge Interchange Format (Сайт KIF [8]), на котором
можно описывать онтологии для последующего обмена знаниями меж-
ду приложениями, а также запрограммирован Web сервис Ontolingua—
система управления знаниями, реализующая описанные выше принци-
пы. В данной главе дается описание языка KIF и его расширений, при-
думанных специально для системы Ontolingua, а также пример постро-
ения онтологии с помощью этих инструментов.
Для редактирования онтологий, система Ontolingua предоставля-
ет специальный инструмент— Онтологический Фреймовый Редактор
1 Грубер также ввел в обращение термин «онтологическое согласование»
(ontological commitment), который означает, что взаимодействующие программные
системы должны иметь договоренности относительно терминологии знаний, раз-
деляемых этими программными системами. В этом смысле, «общая онтология»
(common ontology), т.е. онтология, использующаяся для обмена знаниями между
программными системами, выступает еще и как явная спецификация онтологиче-
ского согласования.
143
(Ontology Frame Editor). Редактор позволяет создавать онтологии, для
добавления их в библиотеку онтологий системы Ontolingua, и добав-
лять в онтологию новые элементы. Создание онтологий и добавление в
них новых элементов облегчено посредством специального инструмен-
тария. Описанию этого инструментария будет посвящен специальный
раздел. Одно из первых описаний системы Ontolingua на русском языке
дано в [1].
Описание языка KIF и его расширения Ontolingua KIF занимает
большую часть данной главы. Язык KIF описан достаточно подробно в
разделе 4.2. Читатель может использовать этот раздел в качестве спра-
вочника по основам языка и сразу перейти к чтению раздела 4.3. Автор
постарался дать подробное описание языков KIF и Ontolingua KIF, учи-
тывая, что на русском языке литературы по этим языкам практически
не существует.
Следует отметить, что система Ontolingua, в нынешнем ее состо-
янии, была создана в 1995 году, т.е. более 10 лет назад. На данный
момент, наиболее популярным языком описания онтологий является
описанный в предыдущей главе язык OWL. Этот язык выбран в каче-
стве стандарта для обмена знаниями в Web. Однако, изучение системы
Ontolingua представляет не только исторический интерес. Необходимо
иметь представления о методах реализации языка описания онтологий,
отличных от OWL. Идеи, лежащие в основе системы Ontolingua, цен-
ны сами по себе и представляют полноценный объект для дальнейших
исследований. Цель данной главы состоит в том, чтобы познакомить
читателя с этой системой и, тем самым, дать новый импульс к ее изу-
чению и развитию.
Проект Ontolingua создавался в лаборатории KSL (Knowledge
Systems, AI Laboratory [9])) Стэндфордского Университета.
4.2 Описание языка KIF
В этом подразделе описание языка KIF (Knowledge Interchange Format)

приведено в соответствии с Руководством по языку KIF (Knowledge
Interchange Format Reference Manual Version 3.0 [11]), а также в соот-
ветствии с предварительной версией ANSI стандарта языка KIF [3].
KIF (Knowledge Interchange Format— Формат для Обмена Знания-
ми) представляет собой формальный язык, созданный для обмена зна-
ниями между различными программными системами. В этом смысле,
язык KIF выполняет в процессе обмена знаниями примерно ту же роль,
что язык XML— в обмене данными: это стандартное средство переда-
144
чи знаний на расстояние. В качестве другой аналогии можно привести
язык Postscript, разработанный компанией Adobe в середине 80-х го-
дов прошлого века с целью стандартизации передачи данных печати с
компьютера на принтер. Печатаемая картинка или текст переводятся в
текст, написанный на языке Postscript, после чего этот текст передается
на принтер. Разработчикам устройств печати достаточно реализовать
процедуру обработки текстов на языке Postscript, чтобы иметь возмож-
ность печатать любую информацию. Точно также, разработчикам си-
стемы управления знаниями достаточно реализовать разбор текстов на
языке KIF, чтобы иметь возможность взаимодействовать с любой дру-
гой системой управления знаниями, которая поддерживает этот язык.
Язык KIF в достаточной степени формализован, чтобы его кон-
струкции могли быть обработаны программными системами, т.е. пред-
назначен, прежде всего, для взаимодействия программных систем друг
с другом. Как следствие, тексты KIF читаются человеком непросто,
хотя, при наличии достаточных навыков, это затруднение легко пре-
одолимо. Также, KIF предназначен для обмена знаниями, а не для их
хранения, поэтому использовать этот язык в качестве основного сред-
ства реализации программной системы обработки знаний не разумно.
Здесь также можно привести аналогию: язык XML используется для
обмена данными между различными программными системами, но для
хранения данных обычно используются так называемые серверы баз
данных— программы, которые разработаны специально для оптималь-
ного хранения данных и быстрого доступа к ним. Точно также, серверы
баз знаний хранят информацию оптимальным образом, а язык KIF ис-
пользуют для взаимодействия друг с другом.
Приведем основные отличительные свойства языка KIF:
1. Язык KIF декларативен. Иначе говоря, можно понять тексты на

языке KIF без применения специальных процедур обработки этих
текстов.
2. Язык KIF в достаточной степени обладает логической вырази-

тельностью. В этом смысле, язык KIF отличается например, от
языка Prolog, в котором логические выражения должны иметь
хорновский вид.
3. Язык предназначен для представления знаний о представлении

знаний. Ввиду этого, нет необходимости вводить новые конструк-
ции для описания тех или иных аспектов представления знания.
145
KIF представляет собой язык исчисления предикатов первого по-
рядка2 и основан на синтаксисе языка LISP (Страница спецификации
LISP [13]). Ввиду последнего, KIF унаследовал все достоинства и недо-
статки языка LISP, например, обилие скобок, которое придает тексту
трудночитаемый для непривычного глаза вид, но также позволяет язы-
ку быть в достаточной степени синтаксически простым без потери вы-
разительности. Свойства синтаксиса языка KIF будут нами подробно
рассмотрены в следующем разделе.
Синтаксис языка KIF

Традиционно для компьютерных языков, KIF можно разделить на три
уровня:
1. На базовом
уровне описание базы знаний на языке KIF рассмат-
ривается как последовательность символов.
2. На лексическом уровне тексты KIF рассматриваются как последо-

вательность лексем,— типизированных слов, составленных из сим-
волов.
3. На синтаксическом уровне текст базы знаний рассматривается как

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

текстов, записанных на языке KIF, позволяя сосредоточиться только
на задачах, связанных со своим уровнем, и тем самым, абстрагиро-
ваться от проблематики других уровней. Так, на лексическом уровне
нет необходимости проводить проверку корректности символов текста
онтологии, т.к. это уже сделано на предыдущем базовом уровне. На
синтаксическом уровне рассматриваются выражения, составленные из
лексем. При этом, проверка того, правильно или нет составлены эти
лексемы, уже сделана на лексическом уровне. Описанные уровни со-
ставляют иерархию, где каждый предыдущий уровень предоставляет
данные для следующего.
2 Хотя язык KIF не имеет прямых конструкций для описания свойств отноше-
ний и функций, он унаследовал от языка LISP возможности обращения к элемен-
там онтологии посредством оператора квотирования (quote) и оператора построения
списков (listof). Это делает язык KIF неявным языком второго порядка. С другой
стороны, Ontolingua KIF уже является полноценным языком второго порядка. На-
пример, инструменты описания различных свойств отношений даны в онтологии
Slot-Constraint-Sugar библиотеки онтологий системы Ontolingua.
146
Для описания синтаксиса будет использоваться несколько изменен-
ная форма нотации Бэкуса-Наура (БНФ) [см. 6]. В этой нотации, все
нетерминальные символы и элементы самой нотации записываются
жирным шрифтом, а символы языка KIF обычным шрифтом. Выра-
жение вида {𝑥1 , 𝑥2 , . . . , 𝑥𝑛 } означает множество терминальных симво-
лов 𝑥1 , 𝑥2 , . . . , 𝑥𝑛 . Выражение вида [нетерминал] означает повторение
символа нетерминал один или ни одного раза. Выражение нетерми-
нал*— повторение ноль или больше раз, выражение нетерминалn̂—
повторение ровно n раз. Выражение [нетерминал1] - [нетерминал2]
означает множество всех элементов [нетерминал1] за исключением
тех, что входят в [нетерминал2]. Выражение int(n) означает деся-
тичное представление целого числа n.
Базовый уровень
Некоторые классы символов удобно обозначить нетерминалами:
∙ Нетерминальный символ space обозначает символ с кодом 32.
∙ Нетерминал tab обозначает символ с кодом 9.
∙ Нетерминал return обозначает символ с кодом 12.
∙ Нетерминал linefeed обозначает символ с кодом 10.
∙ Нетерминал page обозначает символ с кодом 12.
∙ Нетерминал character обозначает множество всех 128 символов
в ASCII кодировке.
∙ Нетерминал empty используется для обозначения пустой строки.
Для обозначения символов алфавита языка KIF используются семи-
битные числа. Соответствие числовых кодов символам задается стан-
дартной кодировкой ASCII. Выделяются следующие классы символов:
∙ Символы верхнего регистра (upper) алфавита английского язы-
ка:
∙ Символы нижнего регистра (lower) алфавита английского языка.
∙ Десять цифр (digits).
∙ Так называемые буквенные символы (alpha), которые не явля-
ются символами алфавита английского языка, но могут исполь-
зоваться в том же контексте, что и символы алфавита.
147
∙ Специальные символы (special).
∙ Пробельные символы (white).
∙ Каждые символ, не входящий в перечисленные выше классы, об-
разует свой собственный класс.
Зададим эту классификацию формально:
upper: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
lower: a b c d e f g h i j k l m n o p q r s t u v w x y z
digit: 0 1 2 3 4 5 6 7 8 9
alpha: ! $ % & * + - . / < = > ? @ _ ~
special: " # ’ ( ) , \ ^ ‘
white ::= space | tab | return | linefeed | page
Класс normal представляет собой объединение классов upper,
lower, digit и alpha:
normal ::= upper | lower | digit | alpha
Лексический уровень
Как уже говорилось выше, на лексическом уровне из текста выделя-
ются лексемы— типизированные слова. Процесс выделения лексем на-
зывается лексическим анализом. Лексический анализ осуществляется
следующим образом:
1. Символы текста читаются до тех пор, пока их комбинация с
предыдущими прочитанными символами формирует лексему.
2. Как только прочитан символ, который не подходит для того, что-

бы быть частью лексемы, сформированной предыдущими симво-
лами, лексический анализатор возвращает предыдущие символы
в качестве лексемы.
3. После этого, лексический анализатор начинает процесс чтения

лексемы заново, причем начиная с того символа, на котором был
остановлен предыдущий цикл чтения лексемы.
Пробелы в описанном выше процессе останавливают цикл чтения лек-
сем, но сами по себе не рассматриваются в качества значащих символов.
В языке KIF имеется пять лексических типов (типов лексем): специ-
альные лексемы, слова, символьные ссылки, строки символов и блоки
символов.
148
Каждый специальный символ формирует свою лексему. Специаль-
ные символы не комбинируются с другими для формирования сложных
лексем. Если специальный символ и присутствует в сложной лексеме,
то только в том случае, когда предваряется символом обратной косой
черты «\», отменяющим специальное значение этого символа.
Слова представляют собой неразрывные последовательность симво-
лов из класса normal, а также других символов, если перед каждым
из них находится символ обратной косой черты. Приведем формальное
определение:
word ::= normal | word normal | word\character
Лексический анализатор не чувствителен к регистру символов, если
только это не символы, предваряемые символом обратной косой чер-
ты. Лексический анализатор преобразовывает все символы лексемы в
верхний регистр, если только символ не предваряется обратной косой
чертой. Таким образом, слова ABC и abc рассматриваются как одни и
те же лексемы, а слово a\bc преобразуется в AbC, которое отличается
от лексемы ABC.
Символьная ссылка всегда предваряется последовательностью #\,
за которой следует символ. Символьные ссылки позволяют ссылаться
на символы непосредственно, чтобы отличать их от обычных символов,
которые могут обозначать другие объекты онтологии.
Строки символов представляют собой символьные последователь-
ности, заключенные в двойные кавычки. В строке может использовать-
ся символ обратной косой черты «\», чтобы отменить специальные зна-
чения символа двойной кавычки (окончания строки) и самого символа
обратной косой черты:
symbol ::= "quotable"
quotable ::= empty | quotable strchar | quotable\character
strchar ::= character - {",\}
Иногда бывает удобно перечислить последовательность произвольных
символов как битовую последовательность, например, если хочется за-
кодировать в тексте некоторое изображение. Для этого KIF предлагает
механизм символьных блоков. Символьный блок— это последователь-
ность символов, начинающаяся с символа #, за которым идет целое
число, задающее размер последовательности, после чего располагается
прописная или строчная «q». Далее, располагаются символы последо-
вательности:
block ::= # int(n) q character^n | # int(n) Q character^n
149
Для грамматического анализа также полезно разделить класс слов
на следующие подклассы: переменные, операторы и константы.
Переменные предваряются символом «?» или символом «@». Пе-
ременная, которая начинается с символа «?», называется индивидной
переменной , а начинающаяся с символа «@» переменная называется
переменной последовательностей .
variable ::= indvar | seqvar
indvar ::= ?word
seqvar ::= @word
Операторы используются для формирования сложных выражений.
Существует три типа операторов: операторы термов, операторы после-
довательностей и операторы определений. Операторы термов исполь-
зуются для формирования сложных термов, операторы последователь-
ностей вместе с пользовательскими операторами формируют сложные
последовательности, а операторы определений используются в опреде-
лениях.
operator ::= termop | sentop | defop
termop ::= value | listof | quote | if
sentop ::= holds | = | /= | not | and | or |
=> | <= | <=> | forall | exists
defop ::= defobject | deffunction | defrelation | deflogical |
:= | :-> | :<= | :=>
Все слова, не входящие в описанные выше подклассы, принадлежат
подклассу констант
.
constant ::= word - variable - operator
С точки зрения семантики, в языке KIF существует четыре типа
констант:
∙ Объектные константы используются для обозначения индивид-

ных объектов.
∙ Функциональные константы обозначают функции, определенные

над индивидными объектами.
∙ Константы отношений используются для обозначения отноше-

ний.
∙ Логические константы выражают различные условия и могут

иметь только два значения: true и false.
150
В языке KIF, в отличии от большинства логических языков, не про-
водится синтаксического различия между описанными выше типами
констант. Любая константа может быть использована точно таким же
образом, как и любая отличная от нее константа. Различие между ти-
пами констант проводится на семантическом уровне.
Синтаксический уровень
На синтаксическом уровне из лексем, выделенных из текста лексиче-
ским анализатором, строятся сложные выражения
. В языке KIF име-
ется три типа выражений:
∙ Термы (terms), которые используются для обозначения объектов

онтологии.
∙ Предложения (sentences), которые выражают факты об описыва-

емом мире.
∙ Определения (definitions), с помощью которых вводятся новые

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

ний. Предложения и определения вместе называются также формами
(forms).
В языке KIF существует девять типов термов: индивидные перемен-
ные, константы, символьные ссылки, символьные строки, блоки симво-
лов, функциональные термы, списочные термы, цитаты и логические
термы. Первые пять видов термов мы уже обсуждали выше, сосредо-
точим свое внимание на последних четырех.
Неявный функциональный терм (implicit functional term) состоит
из константы, обозначающей имя функции и списка аргументов произ-
вольной длины, заканчивающимся необязательной переменной после-
довательности. Как обычно в языке KIF, все это должно быть взято
в круглые скобки. Синтаксических ограничений на число аргументов
функции не налагается, проверка перенесена на семантический уро-
вень.
funterm ::= (constant term* [seqvar])
Явный функциональный терм (explicit functional term) состоит из
оператора «value» и списка аргументов, заканчивающегося необяза-
тельной переменной последовательности. По крайней мере один аргу-
мент должен присутствовать в списке.
151
funterm ::= (value term term* [seqvar])
Терм списка (list term) состоит из оператора «listof» и конечного
списка термов, заканчивающегося необязательной переменной последо-
вательности.
funterm ::= (listof term* [seqvar])
Цитаты (quotations) образуются посредством оператора «quote» и
произвольного списочного выражения (list expression). Списочное вы-
ражение представляет собой, либо атом (atom), либо заключенную в
круглые скобки последовательность списочных выражений. Атом— это
слово, символьная ссылка, символьная строка или символьный блок.
Смысл цитат состоит в том, что списочное выражение, являющееся опе-
рандом оператора «quote», не интерпретируется как выражение языка,
а рассматривается как цитата. Поэтому, списочное выражение не обяза-
тельно должно быть правильно построенным выражением языка KIF.
quoterm ::= (quote listexpr) | ’listexpr
listexpr ::= atom | (listexpr*)
atom ::= word | charref | string | block
Логические термы (logical terms) образуются с помощью операторов
«if> и «cond». Оператор if позволяет проводить проверку, как одно-
го, так и многих условий одновременно. Необязательный терм в конце
списка условий представляет собой значение по умолчанию, которое ис-
пользуется, когда ни одной из условий не выполнено. Оператор cond по-
хож на оператор if, только пары предложение-терм, представляющие
условия, необходимо оборачивать круглыми скобками, и нет значения
по умолчанию в конце списка условий.
logterm ::= (if logpair+ [term])
logpair ::= sentence term
logterm ::= (cond logitem*)
logitem ::= (sentence term)
Рассмотрим, как формируются предложения языка KIF. Ниже приве-
дена БНФ, формально задающая все типы предложений, которые могут
быть в языке KIF. Логические мы уже рассматривали выше.
sentence ::= constant | equation | inequality |

relsent | logsent | quantsent
152
Равенство (equation) состоит из оператора «=» и двух термов. Точно
также определяется неравенство (inequality), только с помощью опера-
тора «/=».
equation ::= (= term term)
inequality ::= (/= term term)
Неявное предложение отношения (implicit relational sentence) состо-
ит из константы и произвольного числа термов, выступающих в каче-
стве аргументов. Последовательность аргументов может заканчиваться
необязательной переменной последовательности. Как обычно, все за-
ключено в круглые скобки.
relsent ::= (constant term* [seqvar])
Явное предложение отношения (explicit relational sentence) состоит
из оператора «holds» и одного или более термов, выступающих в каче-
стве аргументов. Последовательность аргументов заканчивается необя-
зательной переменной последовательности и все это заключено в круг-
лые скобки.
relsent ::= (holds term term* [seqvar])
Заметим, что синтаксис неявного предложения отношения совпада-
ет с синтаксисов неявных функциональных термов. Эту синтаксиче-
скую неоднозначность можно разрешить на основе контекста, в кото-
ром применяется данная синтаксическая конструкция. Каждый неяв-
ный функциональный терм всегда внедрен в некоторое предложение,
а неявное предложение отношения само есть предложение и представ-
ляет собой законченное выражение. Поэтому, данная синтаксическая
неоднозначность не является большой проблемой.
Синтаксис логических предложений (logical sentences) определяет-
ся оператором, который используется в данной выражении. Предложе-
ние, образуемое оператором «not», называется отрицание (negation).
Предложение с оператором «and» называет конъюнкция (conjunction),
а его операнды— конъюнктами (conjuncts). Аналогично, предложение
с оператором «or» называется дизъюнкцией (disjunction), а его опе-
ранды— дизъюнктами (disjuncts). Предложение с оператором «=>» на-
зывается импликацией (implication), а все его аргументы, за исклю-
чением последнего, называются антецедентами (antecedents), послед-
ний операнд называется следствием (consequent). Предложение с опе-
ратором «<=» называется обратной импликацией (reverse implication),
первый аргумент называется следствием, а последующие— антецеден-
тами. Предложение с оператором <=> называется эквивалентностью
(equivalence).
153
logsent ::= (not sentence) |
(and sentence*) |
(or sentence*) |
(=> sentence* sentence) |
(<= sentence sentence*) |
(<=> sentence sentence)
В языке KIF также имеется два вида предложений квантифика-
ции (quantified sentences): предложение квантификации универсально-
сти (universally quantified sentence) образуется с помощью оператора
«forall» и предложение квантификации существования (existentially
quantified sentence) образуется с помощью оператора «exists». В каче-
стве первого аргумента этих операторов выступают списки так назы-
ваемых спецификаций переменных (variable specifications). Специфи-
кация переменной— это, либо переменная, либо список, состоящий из
переменной и терма, представляющего собой отношение, которое огра-
ничивает область определения специфицируемой переменной.
quantsent ::= (forall (varspec+) sentence) |

(exists (varspec+) sentence)
varspec ::= variable | (variable constant)

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

полные
(unrestricted), (complete) и частичные(partial). Для каждого из
этих типов имеется четыре формы определений, в зависимости от того,
что определяется. Определяться могут объекты, функции, отношения и
логические константы. Для определения объектов используется опера-
тор «defobject», для определения функций— оператор «deffunction»,
154
для определения отношений— оператор «defrelation», и для опреде-
ления логических констант используется оператор «deflogical». Ниже
приведена БНФ, формально описывающая синтаксис этих определе-
ний, подробно об определениях мы поговорим ниже.
definition ::= unrestricted | complete | partial
unrestricted ::=
(defobject constant [string] sentence*) |
(deffunction constant [string] sentence*) |
(defrelation constant [string] sentence*) |
(deflogical constant [string] sentence*)
complete ::=
(defobject constant [string] := term) |
(deffunction constant (indvar* [seqvar]) [string] := term) |
(defrelation constant (indvar* [seqvar]) [string] := sentence) |
(deflogical constant [string] := sentence)
partial ::=
(defobject constant [string] :-> indvar :<= sentence) |
(defobject constant [string] :-> indvar :=> sentence) |
(deffunction constant (indvar* [seqvar]) [string]
:-> indvar :<= sentence) |
(deffunction constant (indvar* [seqvar]) [string]
:-> indvar :=> sentence) |
(defrelation constant (indvar* [seqvar]) [string]
:<= sentence) |
(defrelation constant (indvar* [seqvar]) [string]
:=> sentence) |
(deflogical constant [string] :<= sentence)
(deflogical constant [string] :=> sentence)
Как уже говорилось выше, форма (form)— это, либо предложение,
либо определение.
form ::= sentence | definition
Заметим, что определения представляют собой синтаксические кон-
струкции верхнего уровня и, потому, не могут быть часть других пред-
ложений или определений (если, конечно, они не определены внутри
цитат).
Онтология состоит из конечного множества форм. Отметим особо,
что подразумевается именно множество форм, а не их список, т.е.
порядок форм в онтологии не важен. Конечно, порядок может учиты-
ваться программами, которые читают тексты онтологий, с тем, чтобы
155
оптимизировать процесс чтения, но для обмена знаниями между раз-
личными программными системами это не важно.
Базовая семантика KIF

В языке KIF мир, подобно многим логическим языкам, описывается по-
средством выделения объектов и отношений между этими объектами.
Предметная область (universe of discourse) представляет собой множе-
ство всех объектов, существующих или гипотетически могущих суще-
ствовать в данном мире. Понятие объекта трактуется довольно широ-
ко. Объекты могут быть конкретными (определенный атом углерода,
Конфуций или Солнце) или абстрактными (число 2, множество целых
чисел или понятие справедливости), примитивными или составными
(автомобиль, состоящий из запчастей), и даже функциональными (еди-
норог, Шерлок Холмс).
Язык KIF является концептуально разнородным (conceptually
promiscuous), в том смысле, что позволяет пользователям описывать
онтологии в своих собственных предметных областях. Иначе говоря,
KIF не требует, чтобы различные пользователи определяли онтологии в
одной и той же предметной области. С другой стороны, KIF концепту-
ально прикреплен (conceptually grounded), т.к. требует, чтобы каждая
предметная область содержала определенные базовые объекты (basic
objects). Опишем эти объекты:
∙ Все числа, действительные и комплексные.
∙ Все ASCII символы.
∙ Все строки ASCII символов конечной длины.
∙ Слова, которые сами по себе являются объектами, вдобавок к объ-

ектам, которые обозначают.
∙ Все конечные списки объектов предметной области.
∙ Специальный объект ничто

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

множеству. Такие объекты называются небазовыми
(non-basic).
156
В языке KIF, связи между объектами имеют форму отношений.
Формально, отношение (relation) определяется как произвольное мно-
жество конечных списков объектов, причем списки могут иметь различ-
ную длину. Каждый такой список представляет собой выборку объек-
тов, которые удовлетворяют данному отношению. Например, отноше-
ние «<» содержит список <2,3>, что фиксирует тот факт, что 2 меньше,
чем 3.
Функция представляет собой специальный вид отношений. Каж-
дой конечной последовательности объектов, называемых аргументами
(arguments), функция сопоставляет уникальный объект, называемый
значением (value). Формально, функция определяется как множество
конечных списков объектов, по одному списку для каждой комбинации
возможных аргументов. В таких списках все элементы, за исключением
последнего, являются аргументами, последний элемент— это значение
функции. Например, функция 1+ содержит список <2,3>, показываю-
щий, что число 3 есть результат прибавления единицы к числу 2.
Заметим, что как функции, так и отношения определяются как мно-
жества списков. В этом смысле, каждая функция есть отношение, но
не каждое отношение представляет собой функцию. Функция не может
содержать двух списков, различающихся только последним элементом
(значением), ведь это означало бы, что функция имеет два различных
значения для одного и того же набора аргументов. Отношения не име-
ют такого ограничения. Например, как уже говорилось выше, функция
1+ содержит список <2,3> и уже не может содержать списки <2,2> или
<2,4>, а определенное выше отношение «<» содержит списки <2,3>,
<2,4> и <2,5>.
В отличии от математической традиции, в которой списки отноше-
ний и функций должны быть одной и той же длины для каждого фик-
сированного отношения или функции, в языке KIF этого ограничения
не вводится. Например, отношение «<» может содержать, как список
<2,3>, так и список <2,3,4>. Это послабление не ведет к каким-либо
значащим математическим особенностям, но часто бывает удобно.
Объект ничто
В языке KIF все функции полны(total) в том смысле, что для каж-
дой комбинации своих аргументов должны предоставлять определен-
ное значение. Но иногда бывает так, что для некоторых комбинаций
значение функции не имеет смысла. Поэтому, для таких комбинаций
в качестве значения функции выступает объект ничто. Рассмотрим,
например, функцию извлечения квадратного корня, определенную на
157
множестве вещественных чисел. Эта функция не имеет смысла на от-
рицательных значениях, т.е. функция частичная. В KIF определять ча-
стичные функции не позволено, поэтому для отрицательных аргумен-
тов значением функции является ничто.
Функциональные термы
Семантика функционального терма определяется его значением. Значе-
ние функционального терма без переменной последовательности полу-
чается приложением функции, которую обозначает константа в функ-
циональном терме, к аргументам, перечисленным а данном функцио-
нальном терме. Например, значение функционального терма (+ 2 3)
задается приложением функции + к аргументам 2 и 3. В результате при-
ложения функции получается значение 5. Это значение обычно пред-
ставляется в онтологии объектной константой 5.
В том случае, когда функциональный терм заканчивается перемен-
ной последовательности, значение функционального терма формирует-
ся из его аргументов, явно перечисленных в функциональном терме, и
тех аргументов, которые составляют значение переменной последова-
тельности. Пусть, например, значение переменной последовательности
@1 есть список из трех чисел <2,3,4>. Тогда, значение функциональ-
ного терма (+ 1 @1) будет определяться приложением функции + к
списку аргументов <1,2,3,4>, т.е. будет равно значению, обозначаемо-
му объектной константой 10.
Предложения с отношениями
Простое предложение отношения без переменной последовательность
есть истина в том, и только в том случае, когда отношение, обозначае-
мое константой в предложении последовательности, истинно на списке,
формируемом аргументами, перечисленными в предложении отноше-
ния. Если рассматривать отношение как множество списков, то пред-
ложение отношения истинно тогда и только тогда, когда список, форми-
руемый аргументами предложения, принадлежит отношению, которое
обозначает константа данного предложения отношения.
Если предложение отношения оканчивается переменной последова-
тельности, то список отношения формируется из явно перечисленных
аргументов предложения отношения и элементов данной переменной
последовательности.
158
Равенства и неравенства
Равенство истинно, если и только если, термы, входящие в равенство,
обозначают одни и те же объекты данной предметной области.
Неравенство истинно в том, и только в том случае, когда термы,
перечисленные в неравенстве, обозначают различные объекты данной
предметной области.
Истина и ложь
Значение константы true есть истина, а значение константы false есть
ложь.
Семантика логических конструкций

Логические термы
Значение логического терма, сформированного с помощью опера-
тора if, есть терм, входящий в первую пару условие-значение,
условие которой истинно. Например, значение логического терма
(if (> 1 2) 1 (> 2 1) 2) будет равно 2, т.к. первое условие (> 1 2)
ложно и только второе условие (> 2 1) истинно. Если ни одно из усло-
вий в списке не является истинным, то значением терма является по-
следний необязательный терм, если таковой отсутствует, то значение—
это объектничто . Например, в терме (if (> 1 2) 1 (> 2 3) 2 7) оба
условия не являются истинными, поэтому его значением будет 7. Если
бы число 7 отсутствовало в терме, то его значением было бы ничто .
Другой пример: вычисление абсолютного значение числа с помощью
логического терма (if (> a 0) a (- a)).
Аналогично, значение логического терма, формируемого с помощью
оператора cond, есть терм, входящий в первую пару (условие, терм),
для которой условие истинно. Если ни одно из условий не является
истинным, то значением логического терма является объект ничто .
Логические предложения
Отрицание истинно тогда и только тогда, когда предложение, входящий
в конструкцию отрицания, есть ложь.
Конъюнкция истинна тогда и только тогда, когда истинны ее конъ-
юнкты.
Дизъюнкция истинна в том и только в том случае, если хотя бы
один из дизъюнктов является истинным.
159
Если каждый входящий в импликацию антецедент является истин-
ным, то предложение импликации является истинным тогда и только
тогда, когда истинно его следствие. Если хотя бы один из антецедентов
является ложным, то значение всего предложения является истинным,
несмотря на то, истинно или нет следствие.
Значение предложения обратной импликации есть в точности то же,
что и при прямой импликации, если принимать во внимания обратное
расположение антецедентов и следствия.
Значение предложения эквивалентности выражается с помощью
конъюнкции прямой и обратной импликаций его операндов.
Предложения с квантификаторами
Простое предложение с квантификатором существования (т.е. предло-
жение, в котором первый аргумент это список переменных) является
истинным в том и только в том случае, если квантифицируемое пред-
ложение истинно для каких-то значений переменных в списке первого
аргумента.
Простое предложение с универсальным квантификатором (т.е. пред-
ложение, в котором первый аргумент это список переменных) является
истинным в том и только в том случае, если квантифицируемое пред-
ложение истинно для всех значений переменных в списке первого ар-
гумента.
Предложения с квантификацией и сложным определением перемен-
ных можно конвертировать в простые предложения с квантификацией,
переведя условия определения в тело предложения. При этом, может
потребоваться переименование переменных, чтобы избежать конфлик-
тов имен. В примерах ниже сложные определения переменных конвер-
тируются в простые предложения с квантификацией:
(forall (... (?x r) ...) s)

(forall (... ?x ...) (=> (r ?x) s))
(exists (... (?x r) ...) s)

(exists (... ?x ...) (and (r ?x) s))
Как уже говорилось выше, значение свободных переменных в пред-

ложениях зависит от контекста. Если предложение используется в
утверждениях, то переменных квантифицируются квантором всеобщ-
ности. Если предложение используется в запросах, то квантором суще-
ствования. Таким образом, семантика свободных переменных зависит
от контекста использования предложения. Для того, чтобы определить
160
одну и ту же семантику для всех контекстов, необходимо использовать
явную квантификацию.
Определения
В языке KIF, операторы определений позволяют пользователям уста-
навливать предложения «истинными по определению». В этом смысле,
такие предложения отличаются от обычных логических предложений
языка KIF, которые выражают связи между объектами онтологии и
могут быть как истинными, так и ложными. Определения истинны по-
тому, что так захотел пользователь, т.е. семантика определений прин-
ципиально отличается от семантики обычных логических предложений.
Определения имеют содержание— предложения, которые можно ис-
пользовать для вывода других предложений. В языке KIF, каждое
определение имеет соответствующее множество предложений, называ-
емое содержанием (content) определения.
Для определения объектов используется оператор defobject. Ниже
приведены возможные формы этого оператора, вместе с перечислением
их содержания. Первое определение представляет собой равенство, в ко-
тором объектная константа приравнивается терму. Второе определение
состоит из нескольких компонентов, т.о. содержание этого определения
представляет собой конъюнкцию этих компонентов. Содержимое тре-
тьего и четвертого определений представляет собой прямую и обратную
импликации, соответственно. Первой строкой дано само определение, а
второй— аксиомы, которые задают данные определения.
(defobject s := t)
(= s t)
(defobject s p1 ... pn)

(and p1 ... pn)
(defobject s :-> v :=> p)

(=> (= s v) p)
(defobject s :-> v :<= p)

(<= (= s v) p)
Оператор deffunction используется для определения функций.

Возможные формы определения также перечисленны ниже, вместе с
аксиомами, которые задают эти определения. Первое определение зада-
ет равенство двух термов: функциональной константы имени функции
161
и переменных в списке аргументов с одной стороны, и определяемого
терма— с другой. Во втором определении, также как и в случае опре-
деления объектов, содержимое определяемой функции представляется
собой конъюнкцию своих компонентов3 . Третье и четвертой определе-
ния задают прямую и обратную импликации, соответственно.
(deffunction f (v1 ...vn) := t)

(= (f v1 ...vn) t)
(deffunction f p1 ...pn)
(and p1 ...pn)
(deffunction f (v1 ... vn) :-> v :=> p)

(=> (= (f v1 ... vn) v) p)
(deffunction f (v1 ... vn) :-> v :<= p)

(<= (= (f v1 ... vn) v) p)
Для определения отношений используется оператор defrelation.

Снова, возможные формы определения перечислены ниже. Первое
определение представляет собой эквивалентность между отношением,
задаваемым константой со списком аргументов и некоторым предложе-
нием. Последующие определения аналогичны тем, что использовались
выше для объектов и функций.
(defrelation r (v1 ...vn) := p)

(<=> (r v1 ...vn) p)
(defrelation r p1 ...pn)
(and p1 ...pn)
(defrelation r (v1 ... vn) :=> p)

(=> (r v1 ... vn) p))
(defrelation r (v1 ... vn) :<= p)

(<= (r v1 ... vn) p))
3 Читателю следует обратить внимание, что обозначение аргументов функций в
данной нотации всегда начинается с символа «v» (variable— переменная), а обозна-
чение элементов содержания— с символа «p» (part— элемент содержания). Поэтому,
в первом определении задается список аргументов функции, а во втором— ее содер-
жание.
162
Числа и списки
Числа
Как уже говорилось выше, любая онтология, описываемая на языке
KIF, должна включать в себя в качестве базовых объектов все веще-
ственные и комплексные числа. Рассмотрим подробно, как представля-
ются в KIF числа.
Числовые константы записываются в KIF в виде десятичных чисел,
т.е. чисел, имеющих основание 10. Среди прочего, это означает, что
для различных числовых констант всегда можно установить их нера-
венство, т.е. если t1 и t2 представляют различные числа, то выражение
(/= t1 t2) всегда есть истина.
На числах введены отношения, позволяющие выделять подклассы
чисел. Опишем их.
Класс всех чисел задается отношением number и представляет собой
объединение классов real и complex:
(defrelation number (?x) :=

(or (real ?x) (complex ?x)))
Для любого терма t выражение (number t) означает, что этот терм
есть число, выражения (real t) и (complex t)— что терм t есть дей-
ствительное и комплексное числа, соответственно.
Определен класс integer целых чисел. Также, определены классы
рациональных и натуральных чисел:
(defrelation rational (?x) :=

(exists (?y) (and (integer ?y) (integer (* ?x ?y)))))
(defrelation natural (?x) :=

(and (integer ?x) (>= ?x 0)))
На числах определены отношения сравнения, а также еще несколь-

ко отношений, позволяющих выделять специальные подклассы. Среди
них можно назвать отношения positive (положительные), negative
(отрицательные), odd (четные) и even (нечетные).
Также, на числах определено большое количество функций. Это ос-
новные арифметические функции, такие как + (сложение), - (вычита-
ние), * (умножение) и / (деление). Интересные функции это 1+ (увели-
чение на единицу) и 1- (уменьшение на единицу). Для получения более
детальной информации заинтересованный читатель может обратиться
к документации по языку KIF (см. [3]).
163
Списки
Список представляет собой конечную последовательность элементов.
Элементами списков могут быть любые объекты предметной области.
Для обозначения списка элементов t1, . . . , tn в языке KIF
используется терм вида (listof t1 ... tn). Например, выраже-
ние (listof mary (listof tom dick harry) sally) обозначает спи-
сок, состоящий из объекта mary, списка объектов tom, dick и harry,
и объекта sally.
Для выделения списков в тип используется отношение list (спи-
сок)4 , которое определено следующим образом:
(defrelation list (?x) :=

(exists (@l) (= ?x (listof @l))))
Объектная константа nil обозначает пустой список, а отношение
null позволяет проверять, является ли данный список пустым или нет:
(defobject nil := (listof))
(defrelation null (?l) :=

(= ?l (listof)))
Также, определены отношения single, double и triple, позволяю-

щие выделять списки из одного, двух и трех элементов, соответственно.
Для выделения подсписков определены функции first (первый эле-
мент), rest (список, состоящий из всех элементов, кроме первого), last
(последний элемент) и butlast (список, состоящий из всех элементов,
кроме последнего):
(deffunction first (?l) :=

(if (= (listof ?x @items) ?l) ?x)
(deffunction rest (?l) :=

(cond ((null ?l) ?l)
((= ?l (listof ?x @items)) (listof @items))))
(deffunction last (?l) :=

(cond ((null ?l) bottom)
((null (rest ?l)) (first ?l))
(true (last (rest ?l)))))
4 Точнее говоря, «непустой список».
164
(deffunction butlast (?l) :=
(cond ((null ?l) bottom)
((null (rest ?l)) nil)
(true (cons (first ?l) (butlast (rest ?l))))))
В последних двух определениях используется объект ничто

, обо-
значаемый константой bottom.
В KIF определено довольно много функций для работы со списка-
ми, для получения подробной информации заинтересованный читатель
может обратиться к документации по языку KIF [см. 3].
4.3 Ontolingua KIF
Хотя язык KIF является полноценным языком описания знаний, в нем

есть один принципиальный недостаток: язык не поддерживает идиомы
классов и их атрибутов. Как читатель неоднократно мог убедиться вы-
ше, описание мира в терминах классов и их экземпляров выглядит наи-
более удобным для человека способом концептуализации. Поэтому, со-
здатели системы Ontolingua расширили язык KIF таким образом, что-
бы он включал в себя способы определения классов, атрибутов классов
и экземпляров классов. Кроме этого, был изменен, на более удобный,
синтаксис определений отношений и функций, а также введены новые
синтаксические конструкции, позволяющие манипулировать онтологи-
ями непосредственно в тексте онтологии. Этот расширенный язык KIF
мы будем далее называть Ontolingua KIF . В данном разделе будет дано
описание этого языка, а также будут более подробно освещены вопросы,
связанные с концептуализацией посредством классов и их экземпляров.
Подробное описание языка Ontolingua KIF дано в Руководстве по си-
стеме Ontolingua [10].
Расширения языка KIF

Определение отношений
Отношения по прежнему трактуются как множества списков, но теперь
эти списки должны иметь одну и ту же длину. Для определения отно-
шений используются две схожих синтаксических конструкции. Первая
конструкция использует ключевое слово create-relation:
(create-relation <имя-отношения> (<имя-переменной>+)

[:documentation <комментарий>]
165
{:def | :iff-def} <предложение-с-аргументами>
[:constraints <предложение-с-аргументами>]
[:equivalent (<предложение-с-аргументами>*)]
[:sufficient <предложение-с-аргументами>]
[:default-constraints (<предложение-с-аргументами>*)]
[:axiom-def <предложение-без-аргументов>]
[:axiom-constraints <предложение-без-аргументов>]
[:axiom-defaults (<предложение-без-аргументов>*)]
[:ontology <имя-онтологии>]
[:class-slots (<спецификация-слота>*)]
[:instance-slots (<расширенная-спецификация-слота>*)]
[:default-slot-values (<спецификация-слота>*)]
[:issues <дерево-issue>])
Данная конструкция создает отношение с именем <имя-отношения>.
Список переменных, идущий за именем отношения и задаваемый в
определении синтаксиса конструкцией (<имя-переменной>+), содержит
в качестве элементов только индивидные переменные. Запрещено ис-
пользование переменных последовательности, и именно из этого следу-
ет, что списки отношений имеют одну и ту же длину. В KIF индивидные
переменные начинаются с символа ?, в списке (<имя-переменной>+) на-
чинать имя переменной с этого символа не обязательно, но желатель-
но. Остальные элементы синтаксической конструкции не обязательно
должны присутствовать в ней.
Необязательный компонент :documentation <комментарий> пред-
ставляет собой текст, содержащий комментарий к определению. Эле-
менты синтаксической конструкции create-relation могут следовать
в произвольном порядке. Мы не будем перечислять здесь их все, заинте-
ресованный читатель может обратиться к документации [10]. Обратим
внимание только на наиболее важные и чаще всего используемые из
них.
Конструкция :def <предложение-с-аргументами> представляет со-
бой предложение, выражающее необходимое условие выполнения дан-
ного отношения на его аргументах. Рассмотрим, например, отношение
has-parent:
(create-relation has-parent (?child ?parent)
:documentation "отношение ребенка к родителю."
:def (and (person ?child) (person ?parent)))
Это отношение имеет ограничение (and (person ?child)
(person ?parent)), которое логически можно проинтерпретиро-
166
вать следующим образом:
∀𝑥, 𝑦 has-parent(𝑥, 𝑦) ⇒ person(𝑥) ∧ person(𝑦)
Кроме ограничения, выражающего необходимое условие, есть еще

ограничение :iff-def, выражающее достаточное условие.
(define-relation has-mother (?child ?mother)

:documentation "мать ребенка"
:iff-def (and (has-parent ?child ?mother)
(female ?mother)))
В приведенном примере определяется отношение has-mother и огра-
ничение вида :iff-def, которое можно трактовать как
∀𝑥, 𝑦 has-mother(𝑥, 𝑦) ⇔ has-parent(𝑥, 𝑦) ∧ female(𝑦)
Альтернативной и наиболее популярной формой определения отно-

шения является define-relation:
(define-relation <имя-отношения> (<имя-переменной>+)

[<комментарий>]
[:equivalent (<предложение-с-аргументами>*)]
[:default-constraints (<предложение-с-аргументами>*)]
Как видно, эта синтаксическая форма почти ничем не отличается от
формы create-relation, за исключением того, что первым элементом
после списка аргументов отношения должна идти строка комментария,
если, конечно, этот комментарий имеется. Также, ограничения на от-
ношение, вводимые с помощью ключевых слов :def и :iff-def обяза-
тельно должны присутствовать в определении. Строка комментария не
167
предваряется ключевым словом, поэтому для нее порядок задан жест-
ко. Хотя, если использовать ключевое слово :documentation, то ком-
ментарий можно располагать в любом месте. Приведем определения
отношений из примеров предыдущего подраздела, но с использованием
ключевого слова define-relation.
(define-relation has-parent (?child ?parent)

"отношение ребенка к родителю."
:def (and (person ?child) (person ?parent)))
(define-relation has-mother (?child ?mother)

"мать ребенка"
:iff-def (and (has-parent ?child ?mother)
(female ?mother)))
Элемент :issues используется для задания дополнительной инфор-

мации к определению, не относящейся напрямую к спецификации дан-
ного определения. Это так называемое «lisp-дерево», которое может
быть, либо строкой (например, с именами авторов определения), ли-
бо списком строк (содержащими информацию различного рода), либо
списком пар вида («метка»; «объект-lisp»), где в качестве метки высту-
пает имя комментария (имена меток начинаются с двоеточия). Напри-
мер:
:issues ("Это дополнительная информация о функции FOO."
(:example (= (foo ?x) (inverse (bar ?x))))
("Строкой выше пример использования функции"))
Элемент :issues одинаков для всех конструкций определений, поэтому
объяснять его устройство в других конструкциях мы больше не будем.
Как читатель уже, вероятно, убедился, конструкции вида
define-элемент и create-элемент, практически, эквивалентны.
Поэтому, далее мы будем рассматривать более популярную конструк-
цию вида define-элемент, а за деталями заинтересованный читатель
всегда может обратиться к Руководству по системе Ontolingua ([10]).
Определение функций
Как уже говорилось выше, функции представляют собой специальный
вид отношений. Синтаксис определения функций в Ontolingua KIF так-
же имеет две формы: create-function и более простую и чаще исполь-
зуемую форму define-function. Как уже говорилось выше, мы будем
рассматривать только форму define-function.
168
Форма define-function имеет следующий синтаксис:
(define-function <имя-функции> (<имя-переменной>+)
[:-> <имя-переменной-результата>]
[{:def | :iff-def} <предложение-с-аргументами>]
[:constraints <предложение-без-аргументов>]
[{:lambda-body | :=} <выражение-терм-без-аргументов>]
[:issues <дерево-issue>]
[:result-variable <имя-переменной>])
Здесь <имя-функции> означает константу, представляющую собой имя
функции, а <имя-переменной>+— список аргументов функции. Синтак-
сическая конструкция «:-> <имя-переменной-результата>» использу-
ется для обозначения переменной, представляющей результат приложе-
ния данной функции к ее аргументам. Эта конструкция не обязатель-
на, но если определение переменной результата присутствует, то оно
должно идти сразу после списка аргументов. Рассмотрим некоторые
наиболее интересные из перечисленных выше элементов синтаксиче-
ской конструкции определения функции.
Ключевое слово :axiom-def используется для задания аксиом, вы-
ражающих свойства определяемой функции. Ввиду того, что аксио-
мы характеризуют свойства функции, а не ее аргументов, предложе-
ние определения аксиомы не должно содержать имен переменных ар-
гументов. Каждая аксиома представляет собой конструкцию второго
порядка, т.к. характеризует функцию. Рассмотрим, например, функ-
цию identity, которая возвращает в качестве значения переданный на
вход аргумент:
(define-function identity (?anything) :-> ?same-thing
"возвращает свои аргументы"
:lambda-body ?anything
:axiom-def (and (symmetric-function identity)
(transitive-function identity)))
Здесь аксиома, следующая за ключевым словом :axiom-def, задает
свойства функции identity. Данная функция определена как симмет-
ричная и транзитивная.
169
Конструкция :when используется в полиморфных определениях
функций. Полиморфизм функции выражается в том, что может иметь-
ся несколько определений функции с одним и тем же именем. Это полез-
но, когда функция ведет себя по разному с разными типами аргументов.
Например, можно определить функцию «+» для пары множеств как их
объединение, хотя для чисел эта функция означает арифметическое
сложение:
(define-function + (?x ?y) :-> ?z

:when (and (set ?x) (set ?y))
:lambda-body (union ?x ?y))
В данном определении, конструкция :when налагает ограничение на тип
аргументов функции: каждый из аргументов должен быть множеством.
Наконец, наиболее важная конструкция :lambda-body, представля-
ющая собой тело функции, т.е. выражение, которое используется для
вычисления результата приложения функции к ее аргументам. Вместо
ключевого слова :lambda-body можно использовать конструкцию :=.
Выражение тела функции должно быть термом (term expression), т.е.
возвращать некоторое значение— результат вычисления терма. В языке
KIF есть два типа выражений: выражения-термы, которые обозначают
некоторый объект, и выражения, которые выражают факты о связях
между объектами, и могут быть истинными или ложными, в зависимо-
сти от того, выполняются или нет эти связи на конкретных объектах.
Логически, переменная результата эквивалентна терму тела функции,
т.е. значение вычисляемое в теле функции, можно получить также и
через переменную результата. Рассмотрим пример:
(define-function squared (?n) :-> ?value

:def (and (number ?n)
(nonnegative-number ?value))
:lambda-body (* ?n ?n))
Здесь, тело функции— это просто произведение аргумента на себя, т.е.
квадрат числа, передаваемого как аргумент. Ограничение, задаваемое
ключевым словом :def, здесь определяет типы аргумента и возвраща-
емого значения: «number ?n» и «nonnegative-number ?value». Напом-
ним, что ключевое слово :def задает необходимые условия, которым
должны удовлетворять аргументы и значения функции.
170
Определение онтологий
Онтологии в системе Ontolingua представляются в виде модулей,— тек-
стов, содержащихся в файлах с расширением «lisp». Онтология обычно
состоит из нескольких таких модулей: главного модуля, состоящего из
определений, содержащихся в главном файле, и включенных в данную
онтологию других онтологий. Онтология объявляется с помощью стан-
дартной конструкции define-ontology. Приведем ее синтаксис (наибо-
лее часто используемые элементы):
(define-ontology <имя-онтологии> ([<имя-онтологии>]*)

[:generality {:very-low | :low |:moderate | :high
| :very-high | :private}]
[:maturity {:very-low | :low |:moderate | :high
| :very-high | :private}]
[:io-package <имя-пакета>]
[:issues <дерево-lisp>])
Конструкция <имя-онтологии> представляет собой константу, кото-
рая является именем онтологии. Список онтологий, которые использу-
ются в данной онтологии, задается конструкцией [<имя-онтологии>]*.
Как видно из определения, любая онтология может включать любое
число онтологий.
За обязательной частью определения могут идти необязательные.
Здесь приведены только наиболее часто используемые из них. Как
обычно, для всех определений Ontolingua KIF, сразу после обязатель-
ной части может идти комментарий к определению онтологии. Далее,
могут идти параметр общности онтологии (:generality) и индикатор
стадии процесса разработки (:maturity). Параметр общности исполь-
зуется для указания уровня обобщения данной онтологии. Если онтоло-
гия создана для конкретных задач и может использоваться только для
данной задачи, то значение параметра общности необходимо выставить
в :low. Остальные ключевые слова задают различные уровни общно-
сти. Тоже самое касается и индикатора стадии процесса разработки
онтологии. Имеется еще один уровень :very-low, если параметр общно-
сти или индикатор уровня разработки установлены в данное значение,
то ключевые слова :generality и :maturity просто не показываются.
Ключевое слово :private используется, когда онтология разрабаты-
вается для каких-то внутренних целей и не должна быть показана в
списке онтологий пакета.
171
Имя пакета, задаваемое с помощью ключевого слова :io-package,
обычно является именем ontolingua-user, для всех онтологий, создан-
ных пользователями посредством редактора Ontolingua Editor.
Ключевое слово :issues задает различные комментарии к публика-
ции онтологии. Это может быть, либо строка, либо список строк, либо
список пар вида (<метка> <объект-lisp>), где <метка> представляет
собой строку или символ, представляющую тип комментария. Обычно,
:issues содержит строку с именами авторов онтологии. Для других
определений, например определений функций, :issues может содер-
жать примеры использования.
Рассмотрим пример, представляющий собой определение онтологии
simple-geometry из библиотеки онтологий системы Ontolingua [см. 5]:
(define-ontology simple-geometry
(quantity-spaces
3D-tensor-quantities
standard-dimensions)
"В данной онтологии сделана попытка описать

базовые понятия, используемые в моделировании
механических систем. Список понятий включает
в себя точки, фреймы, позиции и ориентацию, но
не содержит понятия, связанные с объемными
взаимоотношениями (т.е. моделирования поверхностей
или объемных тел не производится)."
:maturity :high
:generality :high
:issues ("(c) 1993, 1994 Gregory R. Olsen
and Thomas R. Gruber"))
В данном примере объявляется онтология simple-geometry, в которой
используются три онтологии quantity-spaces, 3D-tensor-quantities
и standard-dimensions, определена строка комментария и информация
о собственности.
Онтологии можно объединять в пакеты. Пакет— это не онтология,
но объединение онтологий по некоторому признаку, который удобен
пользователю. Например, практически все онтологии, которые вхо-
дят в библиотеку онтологий системы Ontolingua, определены в паке-
те «ontolingua-user», который унаследован от базового пакета «KIF».
Очевидно, что объединение онтологий в пакеты в библиотеке онтоло-
гий системы Ontolingua не связано с их содержанием непосредственно.
172
На самом деле, Ontolingua использует модульную систему языка LISP.
Программы, написанные на языке LISP, хранятся в файлах, а фай-
лы могут быть объединены в пакеты. В языке KIF Extensions каждая
онтология хранится в своем собственном файле и, таким образом, онто-
логии могут объединяться в пакеты. Пользователь может задать пакет,
в который будет помещена редактируемая теория, двумя способами:
1. В определении онтологии использовать ключевое слово

:io-package. Этот способ используется редко.
2. Использовать конструкцию in-package "имя пакета" перед
определением онтологии. Этот способ используется наиболее ча-
сто, конструкция помещается в самом начале текста редактируе-
мой онтологии.
(in-package "ontolingua-user")
Классы и фреймы
Должно быть, любознательный читатель уже задавался вопросом: по-
чему данный раздел называется «Онтология Фреймов», хотя мы гово-
рим о классах и их атрибутах? Наверное, настала пора дать на этот
вопрос подробный ответ.
Теория фреймов была создана Марвином Минским в 1974 году и
опубликована в работе [19]. Эта работа сыграла важную роль в науке
о знаниях, но также сформировала базу для того, что в информати-
ке мы сейчас называем Объектно Ориентированным Подходом (ООП).
Для объяснения того, что такое фрейм дадим слово самому Марвину
Минскому [см. 19]:
Фрейм (frame)— это структура данных для представления

стереотипной ситуации, такой как нахождение в жилой ком-
нате определенного типа или посещение празднования дня
рождения ребенка. С каждым фреймом ассоциируется раз-
личного рода информация. Какая-то ее часть говорит о том,
каким образом необходимо использовать данный фрейм.
Другая часть сообщает, что ожидается после того, как ситуа-
ция, представляемая данным фреймом, произойдет. Инфор-
мация другого рода содержит данные о том, что случится,
если эти ожидания не сбудутся.
Фрейм можно мыслить как сеть узлов и отношений. «Верх-
ние уровени» фиксированы и представляют свойства, ко-
173
торые всегда выполняются для данной ситуации. Нижние
уровни содержат множество «терминалов»5 — «слотов», ко-
торые заполняются специфическими экземплярами или дан-
ными. 6 Каждый терминал может задавать условия, кото-
рым должны удовлетворять данные, чтобы они могли быть
присоединены. (Условия сами представляют собой неболь-
шие «подфреймы»). Простые условия могут быть заданы
посредством «маркеров», которые требуют, чтобы присоеди-
няемые к терминалу данные были персоной, объектом, име-
ющим определенное значение, или указателем на подфрейм
определенного типа. Более сложные условия могут задавать
отношения между данными, присоединенными к каждому
терминалу.
Описание ситуаций с помощью фреймов похоже на представление

понятий в аристотелевском стиле посредством типов и их атрибутов.
Роль типа здесь играет фрейм, а роли атрибутов— слоты. Также, можно
сравнить фреймы с классами, использующимися в ООП, в качестве
атрибутов класса также выступают слоты.
Создатели системы Ontolingua при проектировании языка
Ontolingua KIF попытались совместить логический и фреймовый
подход. Классы (фреймы) представляют собой одноместные отноше-
ния. Одноместное отношение при желании можно трактовать также
и как множества элементов (списков длины один). Классы можно
наследовать друг от друга с помощью отношений subclass-of или
direct-subclass-of. Экземпляры классов можно задавать с помо-
щью отношения instance-of или direct-instance-of. Атрибуты
классов задаются двуместными отношениями, ниже мы это подробно
рассмотрим. Ontolingua KIF также поддерживает прямое задание
фреймов и их слотов с помощью синтаксических конструкций вида
define-frame, :class-slots, :instance-slots и т.п. Эти конструкции
редко используются, поэтому здесь мы из рассматривать не будем. Для
подробной информации заинтересованный читатель может обратиться
к документации по языку Ontolingua KIF [10].
5 Понятие «терминал» здесь используется в «аэровокзальном» контексте. Ана-
логия в том, что также как на различные терминалы могут прибывать различные
самолеты, так и в терминалы фреймов могут быть присоединены другие фреймы,
описывающие определенного вида ситуации.
6 Заметим, что в литературе для обозначения знаний нижнего уровня закрепился
термин «слот». Это уже компьютерный контекст, в котором знания верхнего уровня
представляются в виде компьютерной платы, в слоты которой могут быть вставлены
другие модули (модули памяти, плата видеокарты и т.д.)
174
Далее будет приведено описание основных конструкций, связанных
с определением классов, их экземпляров и отношения наследования
между классами. Определение атрибутов классов в системе Ontolingua
производится с помощью задания отношений обычного вида. Поэтому,
описывать их специально мы здесь не будем, но приведем достаточное
количество примеров в разделе, посвященном изложению иллюстратив-
ного примера.
Классы
Классы можно задавать с помощью синтаксической конструкции
create-class или его упрощенной формы define-class:
(define-class <имя-класса> (<имя-переменной>)
[:equivalent <предложение-с-аргументами>]
[:default-constraints <предложение-с-аргументами>]
Имя класса задается посредством константы <имя-класса>. После
имени класс должно идти имя переменной, которая используется внут-
ри определения класса для ссылки на определяемый класс. Это необхо-
димо, например когда задаются ограничения на использование класса
с помощью конструкций вида :def или :iff-def. Например:
(define-class human (?human)
"Человек как животное."
:def (animal ?human))
В данном определении задается класс human (человек), при этом опре-
деляется, что каждый человек является также и животным (animal).
Это ограничение можно было бы задать, объявив класс animal роди-
тельским классом класса human с помощью отношения subclass-of.
175
Ключевые слова :def и :iff-def используются, как и для других
конструкций, для задания различного вида ограничений на использо-
вание класса. Например, в определении
(define-class female-person (?person)

"женщины"
:iff-def (and (human ?person)
(= (gender ?person) female)))
задается класс female-person (персона женского пола), причем
указывается, что каждый экземпляр класса female-person явля-
ется также и экземпляром класса human (human ?person), причем
пол каждого такого экземпляра обязательно должен быть женским
(= (gender ?person) female).
Экземпляры классов
Экземпляры класса задаются с помощью синтаксической конструкции
define-instance (create-instance):
(define-instance <имя-экземпляра> (<имя-класса>+)
[:= <выражение-терм-без-аргументов>]
[:slots (<спецификация-слота>*)]
Эта конструкция представляет собой функцию, которая конструиру-
ет объект с именем <имя-экземпляра>, который принадлежит классам
(одноместном отношениям), заданным в списке <имя-класса>+.
Как и всякая функция, конструкция define-instance должна
иметь тело, в котором, собственно, и задается экземпляр класса. Тело
функции специфицируется с помощью двух альтернативных конструк-
ций:
1. := <выражение-терм-без-аргументов>.
2. :axiom-def <предложение-без-аргументов>.
Конструкция := <выражение-терм-без-аргументов> используется

для задания объектов класс непосредственно с помощью термов. На-
пример:
176
(define-instance PI (real-number)
"Число PI представляет собой отношение длины
окружности к его диаметру."
:= 3.145)
Здесь определяется константа PI, как экземпляр класса вещественных
чисел, равная 3.145.
Экземпляры класса можно не только задавать с помощью термов, но
и просто записывать какие-то интересные факты об этих экземплярах
с помощью конструкции :axiom-def <предложение-без-аргументов>.
Например, в определении7
(define-instance Fred (guys-with-generic-names)

"Стандартное определение персоны с
распространенным именем."
:axiom-def (usual-temperament fred nice))
задается, что персона по имени Fred является экземпляром
класса guys-with-generic-names (парни с распространенными
именами) и, при этом уточняется, что fred— хороший человек
(usual-temperament fred nice).
Подклассы
Отношение subclass-of определено в Онтологии фреймов следующим
образом (детали опущены):
(define-relation subclass-of (?child-class ?parent-class)
:iff-def (and (class ?parent-class)

(class ?child-class)
(forall ?instance
(=> (instance-of ?instance ?child-class)
(instance-of ?instance ?parent-class))))
:axiom-constraints (transitive-relation subclass-of)

Как видно из определения, это двуместное отношение, принимаю-
щее в качестве параметров переменные ?child-class и ?parent-class.
Эти параметры должны быть классами (class ?parent-class и
7Напоминаем читателю, что в языке KIF, также как и в языке LISP, регистр
символов не различается, поэтому строки «Fred» и «fred» обозначают одну и ту
же константу.
177
class ?child-class). Также задается ограничение, что каждый эк-
земпляр класса ?child-class должен являться экземпляром класса
?parent-class.
Отношение subclass-of также определяется как транзитивное:
:axiom-constraints (transitive-relation subclass-of).
Класс может иметь более одного дочернего и более одного роди-
тельского классов. В объектно-ориентированных системах часто разде-
ляют понятия дочернего класса, который явно определен как дочерний
с помощью конструкции subclass-of, и подкласса, который выведен
из свойств отношений наследования на классах. Например, из опреде-
лений «subclass-of C1 C2» и «subclass-of C2 C3» можно вывести,
что должно выполняться «subclass-of C1 C3». Функциональный ин-
терфейс таких систем предоставляет возможность для данного класса
получить все его «определенные» родительские (дочерние) классы и все
его «выведенные» родительские (дочерние) классы. Система Ontolingua
не делает подобных различий. В этом смысле все классы, и выведенные
через свойство транзитивного отношения subclass-of, и определенные
явно, не различаются.
4.4 Онтология библиографических данных
В данном разделе мы, в целях иллюстрации, рассмотрим пример он-

тологии библиографических данных, именуемой «Bibliographic-Data»,
разработанный Томасом Грубером специально для целей обучения. Он-
тология является частью библиотеки онтологий системы Ontolingua. В
следующем разделе мы рассмотрим подробно, как получить доступ к
данной библиотеке и, даже, как добавлять в библиотеку новые онтоло-
гии.
Основное назначение онтологии библиографических данных состо-
ит в том, чтобы определить понятия и отношения, которые лежат в
основе баз данных и инструментов, связанных с библиографическими
данными. Таким образом, данную онтологию можно мыслить, как кон-
цептуальную схему базы библиографических данных. В этом смысле,
онтология «Bibliographic-Data» может служить основой для автомати-
ческого обмена данными между различными библиотеками. Каждая
библиотека может расширить данную онтологию, наполнив ее своими
конкретными данными, но при этом, оставляя себе возможность пере-
вода формата данных на формат других библиотек.
Определение онтологии библиографических данных выглядит сле-
дующим образом (комментарии опущены):
178
(define-ontology Bibliographic-Data
(simple-time agents frame-ontology
slot-constraint-sugar documents)
:io-package "ontolingua-user"
:maturity :High)
Как видно из определения, онтология библиографических дан-
ных использует онтологии: simple-time, agents, frame-ontology,
slot-constraint-sugar и documents. Онтология определена в пакете
ontolingua-user.
Основным элементом онтологии библиографических данных явля-
ется понятие ссылки (reference). Ссылка описывает информацию, необ-
ходимую, чтобы идентифицировать и получить публикацию. Публика-
ция ассоциируется с документом (document), который может быть раз-
личного сорта (например, книгой или журналом). Иногда, для одного
документа имеет сразу несколько публикаций (например, статьи в сбор-
нике конференции). Поэтому, в онтологии произведено разделение меж-
ду документом и ссылкой. Документы создаются авторами (authors),
которые чаще всего являются людьми (people), но иногда могут быть и
другими агентами, например, организациями (organizations). Докумен-
ты публикуются издателями (publishers).
Класс ссылки определен следующим образом:
(define-class Reference (?ref)
"Библиографическая ссылка представляет собой описание

публикации, которое однозначно идентифицирует эту
публикацию, предоставляя информацию, необходимую для
получения ассоциированного документа. Ссылку следует
отличать от ссылки в тексте документа, которая не
указывает на документ, но на ссылку, идентифицирующую
данный документ.
Информация, ассоциированная с ссылкой, содержится
в полях данных, описываемых двуместными или
одноместными отношениями.
Каждая ссылка имеет обязательные поля: автор,
название и год издания."
:def (Individual-Thing ?Ref)

:axiom-def (partition Reference
(setof Publication-Reference
179
Non-Publication-Reference)))
В определении задается, что каждая ссылка является экземпляром
класса Individual-Thing. Этот класс определен в Онтологии фреймов
(Frame-Ontology) для того, чтобы отличать классы от индивидов. Та-
ким образом, здесь просто декларируется, что ссылка— это не класс.
Конструкция :axiom-def определяет, что класс Reference являет-
ся непересекающимся объединением классов Publication-Reference
и Non-Publication-Reference. Для этого используется отношение
partition, определенное в онтологии Frame-Ontology.
Таким образом, класс Reference имеет два дочерних клас-
са: Publication-Reference и Non-Publication-Reference. Класс
Publication-Reference представляет собой ссылку на опубликован-
ный документ. Конечно, понятие публикации и документа здесь ин-
терпретируются несколько шире, чем обычно. Приведем определение
этого класса:
(define-class Publication-Reference (?ref)

:def (and (Reference ?ref)
(Has-One-Of-Type Ref.document
?ref
Document)
(Has-One ?ref Title-Of))
:axiom-def (Disjoint-Decomposition
Publication-Reference
(setof Book-Reference
Book-Section-Reference
Article-Reference
Proceedings-Paper-Reference
Thesis-Reference
Technical-Report-Reference
Misc-Publication-Reference)))
В определении класса задается, что каждый экземпляр клас-
са Publication-Reference является также и экземпляром класса
Reference. Кроме того, определяется, что класса имеет два атрибута:
Ref.document и Title-Of. Также, определяется множество подклассов
данного класса.
Класс Non-Publication-Reference задает ссылку на что-нибудь,
что не является документом. Отношение Cannot-Have как раз и
задает это ограничение (Cannot-Have ?ref Ref.Document). Также
180
определяются два подкласса: Personal-Communication-Reference и
Generic-Unpublished-Reference.
(define-class Non-Publication-Reference (?ref)
:def (and (Reference ?ref)
(Cannot-Have ?ref Ref.Document))
Non-Publication-Reference
(setof Personal-Communication-Reference
Generic-Unpublished-Reference)))
Для классов ссылок определено множество атрибутов, здесь мы не
будем их перечислять.
Класс документа задается в онтологии Documents следующим обра-
зом:
(define-class Document (?doc)
"Документ есть нечто, что создается автором (авторами) и

что может быть просмотрено, прослушано и т.д. Документ
должен существовать в материальной форме (например,
концерт или исполняемая пьеса не являются документами).
Документы обычно расположены в библиотеках.
:def (and (Individual-Thing ?doc)

(Has-One ?doc Title-Of))
Document
(setof Book
Periodical-Publication
Proceedings
Thesis
Technical-Report
Miscellaneous-Publication)))
Определения классов автора, издателя, людей и организаций мы
здесь приводить не будем.
Онтология библиографических данных включает в себя онтологию
времени Simple-Time. В этой онтологии определены класс Time-Point,
представляющий собой точку в историческом времени (реальном вре-
мени Земли), и класс Calendar-Date, представляющий ту же точку во
времени, но с точностью до дня (т.е. известны день, месяц и год). Класс
181
Calendar-Year представляет точку во времени с точностью до года. Эле-
менты онтологии Simple-Time используются для обозначения дат пуб-
ликаций документов. Обозначения дат с различной точностью здесь
важно, т.к. для публикации может быть неизвестен ее месяц или день,
а только год. Точки во времени также используются для обозначений
дат конференций (экземпляров класса Conference).
Каждый документ в онтологии имеет название (Title). Название—
это строка символов, также как и имя агента (Agent-Name) или адрес
(City-Address). Подобные типы данных, которые используются для
идентификации, не нуждаются в дополнительном структурировании,
поэтому для них используются встроенные в KIF типы. Вот как, на-
пример, определена в онтологии Documents функция Title-Of:
(define-function Title-Of (?doc)

:-> ?title
:def (and (Document ?doc) (Title ?title)))
Каждое название документа должно быть элементом класса Title,
определенного следующим образом:
(define-class Title (?title)

:def (Individual-Thing ?title))
Некоторые элементы онтологии библиографических данных опреде-
лены в онтологии Agents. Вот, например, как определен класс издателя:
(define-class Publisher (?publisher)
"Издатель - это организация, которая осуществляет издание.

Владелец издания может быть персоной, в этом случае,
имя издателя будет может быть именем персоны."
:def (and (Organization ?publisher)

(Has-One ?publisher Name)))
Онтология библиографических данных использует отношения,
определенные в онтологии Slot-Constraint-Sugar. Это, в основном,
отношения второго порядка, призванные выражать различные огра-
ничения, налагаемые на другие отношения. Например, выше неодно-
кратно использовалось отношение Has-One, определенное в онтологии
Slot-Constraint-Sugar следующим образом:
(define-relation Has-One (?instance ?binary-relation)
182
"Двуместное отношение R имеет значение (Has-One) на
экземпляре i, если существует в точно одно значение v,
такое что выполняется R(i,v).
Когда отношение используется в определении класса,
где ?i представляет собой переменную экземпляра класса,
выражение (Has-One ?i R) означает, что атрибут R всегда
имеет в точности одно значение для данного экземпляра."
:iff-def (and
(Instance-Of ?binary-relation Binary-Relation)
(Cardinality ?binary-relation ?instance ?val)
(= ?val 1)))
4.5 Онтологический Фреймовый Редактор
Онтологический Фреймовый Редактор (Ontology Frame Editor) предо-

ставляет возможности по просмотру библиотеки онтологий системы
Ontolingua8 , добавлении в библиотеку новых онтологий и редактиро-
ванию существующих. Данный раздел посвящен описанию этих воз-
можностей.
Вход в программу Редактора можно осуществить с главной стра-
ницы системы Ontolingua [2]. После перехода на страницу Редактора
[5] необходимо пройти простую процедуру регистрации, чтобы зареги-
стрировать себя в качестве нового пользователя системы, или же можно
войти анонимно (см. рисунок 4.1).
После того, как вход в Редактор осуществлен, пользователь полу-
чает доступ к библиотеке онтологий системы Ontolingua. Онтологии в
библиотеке могут находится в двух состояниях: загруженные в систему
или не загруженные. Перед редактированием онтологии ее необходимо
сначала загрузить в систему, т.е. перевести в новое состояние. Вид спис-
ка загруженных онтологий показан на рисунке 4.2. Читатель, вероятно,
обратил внимание на горизонтальный ряд кнопок, расположенный на
самом верху окна. Назначение всех этих кнопок мы здесь описывать не
8 Эта возможность видится как наиболее интересная особенность Редактора.
Несмотря на свое название, Редактор является не столько инструментом редактиро-
вания, сколько единственным средством доступа к библиотеке онтологий системы
Ontolingua. Тексты онтологий библиотеки располагаются в файлах с расширением
«lisp», которые можно открыть для просмотра и, тем самым, получить доступ к
содержимому онтологии
183
Рис. 4.1: Страница Онтологического Фреймового Редактора
будет, это хорошо сделано в системе контекстной подсказки Ontolingua,

которой пользователь может воспользоваться в любой момент, нажав
на кнопку «Помощь» (Help). Скажем только, что кликнув на кнопке
«Домой» (Home), пользователь может перейти на домашнюю страницу
системы Ontolingua.
Пользователь может загрузить онтологию для просмотра, просто
щелкнув по имени онтологии в списке загруженных онтологий. Если он-
тология не загружена, то необходимо ее будет сначала загрузить. Это
также осуществляется простым кликом на имени онтологии. Также,
можно создать свою онтологию. После клика на имени онтологии осу-
ществляется переход на страницу этой онтологии, на которой пользо-
ватель имеет возможность добавлять в онтологию новые элементы. По-
пробуем добавить новую онтологию с именем «Test-for-Book». Для это-
го необходимо на странице библиотеки онтологий системы Ontolingua
184
Рис. 4.2: Список загруженных онтологий системы Ontolingua.
185
нажать на кнопку «Создать» (Create), выбрав в выпадающем списке
пункт «Онтология» (Ontology). В поле имени онтологии ввести «Test-
for-Book», а в поле комментария— «For test». В качестве включаемых
онтологий выберем только одну: Frame-Ontology (см. рисунок 4.3).
Нажмем на кнопку «Добавить новую онтологию» (Assert new
ontology), Редактор создаст онтологию и осуществит переход на ее стра-
ницу. Страница онтологии содержит описание данной онтологии, при-
чем это описание состоит из разделов. Первый раздел посвящен опи-
санию свойств онтологии как объекта библиотеки онтологий. Фактиче-
ски, это представленная в удобном для человека виде описанная выше
конструкция define-ontology языка Ontolingua KIF. Точнее, описанию
этой конструкции посвящены три ее первых раздела: «Ontology Test-
For-Book», «Ontology documentation» и «Summary of Test-For-Book».
Оставшиеся разделы посвящены описанию элементов онтологии, за-
даваемых с помощью конструкций define-class, define-relation и
define-function. Онтологию необходимо сохранить, тогда ее содержа-
ние станет доступным для просмотра из файла с расширением «lisp» и
именем, совпадающим с именем данной онтологии (см. рисунок 4.4).
Создадим в онтологии Test-For-Book класс с именем Test-Class.
Для этого в выпадающем списке возле кнопки «Создать» (Create) вы-
берем «Класс» (Class) и нажмем на кнопку. Загрузится страница созда-
ния класса. Необходимо ввести имя класса, необязательный коммента-
рий и обязательно указать имя класса, подклассом которого данный
объект будет являться. Мы укажем класс Individual-Thing, опреде-
ленный в онтологии Frame-Ontology специально для определения объ-
ектов, которые не являются множествами элементов. Указание класса
обязательно, потому что в синтаксической конструкции define-class
необходимо указать хотя бы одно ограничение в обязательном элементе
:def или элементе :iff-def. Вид страницы создания класса показан на
рисунке 4.5.
После того, как класс будет создан, система осуществит переход на
страницу класса, на которой можно указать дополнительные свойства
класса, добавить ограничения, слоты и т.п. Мы этого делать не бу-
дем и вернемся на страницу онтологии, для чего можно просто клик-
нуть на имени онтологии левой кнопкой мыши. Также, необходимо не
забыть сохранить изменения, сделанные в онтологии, нажав на кноп-
ку «Файл» (File) и выбрав в выпадающем списке элемент «Сохранить
онтологию...» (Save ontology to...). Теперь текст онтологии можно про-
смотреть как содержимое файла «test-for-book.lisp», для чего достаточ-
но кликнуть на имени этого файла.
Создадим теперь экземпляр класса Test-Class. Для этого, в вы-
186
Рис. 4.3: Создание онтологии Test-For-Book.
187
Рис. 4.4: Страница онтологии Test-For-Book.
188
Рис. 4.5: Страница создания класса Test-Class.
падающем списке кнопки «Создать» (Create) выберем элемент «Ин-

дивид» (Individual) и нажмем на кнопку. Откроется страница со-
здания экземпляра класса. Введем в качестве имени экземпляра
«Instance-Of-Test-Class» и напечатаем в поле «Экземпляр класса»
(Instance-Of) имя «Test-Class». После этого, нажмем кнопку «Доба-
вить нового индивида» (Asset new individual): новый элемент онтологии
будет создан. Вид страницы создания индивида показан на рисунке 4.6.
Наконец, создадим новое отношение. Выберем в выпадающем спис-
ке возле кнопки «Создать» (Create) элемент «Отношение» (Relation)
и нажмем кнопку. Система осуществит переход на страницу создания
нового отношения. Страница содержит три поля: имя отношения, ком-
ментарий и домены (domains). В качестве имени отношения введем
«Test-Relation», а в качестве домена напечатаем «Test-Class». Необ-
ходимо обязательно ввести хотя бы одно имя домена, т.к. конструкция
189
Рис. 4.6: Страница создания экземпляра Instance-Of-Test-Class.
define-relation требует обязательного наличия хотя-бы одной акси-

омы в элементе :def. После этого, нажмем на кнопку «Создать новое
отношение» (Assert New Relation) и отношение будет создано. Не за-
будем сохранить отношение в онтологии и саму онтологию в файле.
При сохранении онтологии необходимо будет выбрать область видимо-
сти онтологии. Это может быть «Только для меня» (Just-to-Me) и «Для
всех» (Universe). Пока формирование онтологии не закончено, лучше не
показывать ее содержание, поэтому автор выбрал опцию «Только для
меня». Вид страницы создания отношения показан на рисунке 4.7.
Содержимое файла онтологии Test-For-Book можно посмотреть,
кликнув на имени файла левой кнопкой мыши. После описанных выше
манипуляций, онтология будет выглядеть следующим образом:
(In-Package "ONTOLINGUA-USER")
190
Рис. 4.7: Страница создания отношения Test-Relation.
(Define-Ontology Test-For-Book
(Frame-Ontology)
"For test."
:Io-Package "ONTOLINGUA-USER")
(In-Ontology (Quote Test-For-Book))
(define-class Test-Class (?X)

"The class is created to illustrate class
creation process."
:def (and (Individual-Thing ?X)))
(define-individual Instance-Of-Test-Class (Test-Class)
191
"Just to illustrate.")
(define-relation Test-Relation (?Test-Class)

"Only to illustrate relation creation process."
:def (and (Test-Class ?Test-Class)))
Система Ontolingua содержит хорошее интерактивное руководство
по обучению пользователей [4]. Процессы добавления новых элементов
в онтологию снабжены подробными иллюстрациями. Автор советует
заинтересованному читателю, перед тем, как начать пользоваться си-
стемой Ontolingua, сначала прочитать это руководство.
Конечно, за недостатком места, не все аспекты системы были рас-
смотрены. Но, автор полагает, что основная цель данной главы, со-
стоящая в том, чтобы возродить интерес пользователей к системе
Ontolingua, в какой-то мере достигнута.
192
1. Бениаминов Е. М., Болдина Д. М. Система представления знаний

Ontolingua— принципы и перспективы. // НТИ, Сер.2, 1999, №10.
2. Главная страница системы Ontolingua.

http://www.ksl.stanford.edu/software/ontolingua.
3. Драфт стандарта dpANS языка KIF.

http://logic.stanford.edu/kif/dpans.html.
4. Интерактивное руководство по изучению системы Ontolingua.

http://www-ksl-svc.stanford.edu:5915/doc/frame-editor/guided-
tour/index.html.
5. Онтологический Фреймовый редактор Ontolingua. http://www-ksl-

svc.stanford.edu:5915/frame-editor.
6. Страница описания формы Бэкуса-Наура на Википедии.

http://ru.wikipedia.org/wiki/Форма_Бэкуса_-_Наура.
7. Сайт компании Adobe. http://www.adobe.com.
9. Сайт KSL. http://www-ksl.stanford.edu/.
10. Страница руководства по системе Ontolingua. http://www-ksl-

svc.stanford.edu:5915/doc/ontolingua/reference-manual/index.html.
11. Страница руководства по языку KIF.

http://logic.stanford.edu/kif/Hypertext/kif-manual.html.
12. Страница языка Postscript на сайте компании Adobe.

http://www.adobe.com/products/postscript/.
13. Страница спецификации языка LISP.

http://www.lispworks.com/documentation/HyperSpec/Front/index.htm.
14. Farquhar A, Fikes R, Rice J. The Ontolingua Server:

A Tool for Collaborative Ontology Construction. //
Knowledge Systems Laboratory, KSL-96-26, September 1996
(http://ontolingua.stanford.edu/).
15. Gruber T. R. A Translation Approach to Portable Ontology

Specifications. Knowledge Acquisition, 5(2): pp. 199-220. (1993)
193
16. Gruber T. R. Ontolingua: A mechanism to support portable ontologies.
// Stanford University, Knowledge Systems Laboratory, Technical
Report KSL-91-66, Март 1992.

18. Karp P. D., Myers K., Gruber T. R. The Generic Frame Protocol.
// In 14th International Joint Conference on Artificial Intelligence.
Montreal, Canada.
19. Minsky M. A Framework for Representing Knowledge. // MIT-AI

Laboratory Memo 306, June, 1974.
20. Steele G. Common Lisp: The Language, 2nd

Edition. // Digital Press, 1990. http://www-
2.cs.cmu.edu/Groups/AI/html/cltl/clm/node1.html.
194
5 Cyc— библиотеки
онтологий для AI
5.1 Что такое Cyc
В данной главе мы рассмотрим библиотеку онтологий под названием

Cyc1 [см. 7]. Cyc представляет собой библиотеку онтологий, описыва-
ющую знания, необходимые для рассуждений на бытовом уровне, т.е.
такие знания, которые человек использует в своей каждодневной дея-
тельности.
Разработка Cyc началась в 1984 году в качестве проекта под ру-
ководством Дугласа Лената в компании Microelectronics and Computer
Technology Corporation (MCC)2 . В 1994 году была учреждена компания
Cycorp, целью которой являлась коммерческая деятельность в области,
связанной с проблематикой искусственного интеллекта.
В системе Cyc для обозначения системы, разрабатывавшейся до
1994 года, используется термин Cyc-9, а для системы, разработанной
1 Имя «Cyc» представляет собой выдержку из английского «enCYClopedia» (эн-
циклопедия) и произносится как «Цик».
2 Компания MCC была создана в 1982 крупнейшими производителями компью-
терной техники США. Основной целью создания компании был ответ на японский
проект создания компьютера пятого поколения (Проект Пятого Поколения), кото-
рый японцы планировали создать к 1991 году. Директором компании был назначен
адмирал Боби Рей Инман, который до этого возглавлял Агентство Национальной
Безопасности США, а также являлся заместителем директора ЦРУ. Компания за-
нималась поддержкой проектов, связанных с разработками в области искусствен-
ного интеллекта. В июне 2000 года, совет директоров компании проголосовал за ее
роспуск.
195
позже— термин Cyc-10. Таким образом, Cyc-10 представляет собой на-
звание текущей реализации системы Cyc. Первая версия Cyc-10 появи-
лась в марте 1995 года и была разработана под руководством Кейта
Гулсби (Keith Goolsbey), архитектора системы и разработчика проце-
дур логического вывода.
Знания в библиотеке онтологий Cyc поделены на так называемые
микротеории . Микротеорий в проекте Cyc тысячи. Микротеория содер-
жит факты, касающиеся той или иной области знаний. В этом смысле,
микротеория представляет собой аналог онтологии. Для записи фактов
в микротеориях Cyc использует специальный язык под названием CycL
(Cyc Language). Язык CycL представляет собой язык исчисления логи-
ки предикатов первого порядка с аксиомами эквивалентности, возмож-
ностями расширения процедур логического вывода и сколемизацией.
Язык также поддерживает некоторые свойства языка второго порядка
(например, квантификацию по предикатам с некоторыми ограничения-
ми). База знаний Cyc состоит из термов (terms)— словаря языка CycL,
и суждений (assertions), связывающих эти термы. Язык CycL также
будет подробно рассмотрен ниже в разделе 5.2.
Система Cyc используется не только, как хранилище для сужде-
ний. Система предоставляет возможности по осуществлению логическо-
го вывода по этим суждениями. О том, каким образом осуществляются
процедуры логического вывода в системе Cyc, мы также поговорим по-
дробно в этой главе в разделе 5.3.
Библиотека онтологий проекта Cyc довольно обширна. Так, извест-
но, что еще в 1994 году, когда была создана компания Cycorp, библиоте-
ка содержала порядка 250 тысяч фактов. Очевидно, что за прошедшие
15 лет, объем знаний, содержащихся в библиотеке, увеличился. На дан-
ный момент, онтология Cyc содержит более миллиона суждений. Для
систематизации такого обширного комплекса знаний в Cyc использу-
ется своя онтология верхнего уровня. Детальному рассмотрению этой
онтологии будет посвящен раздел 5.4.
Библиотека онтологий Cyc закрыта для публичного доступа, но яд-
ро системы все же опубликовано под именем OpenCyc (см. [5]). Кро-
ме библиотеки онтологий, OpenCyc предоставляет набор инструментов,
позволяющих производить различные манипуляции с библиотекой он-
тологий на программном уровне. В этот набор включена программа
для осуществления логического вывода Cyc Inference Engine, програм-
ма для просмотра содержимого библиотеки онтологий Cyc Knowledge
Base Browser, а также набор различных программных интерфейсов для
работы с библиотекой. Мы рассмотрим инструментарий OpenCyc более
подробно в разделе 5.5.
196
В проекте Cyc также реализована система обработки естественных
языков под названием Cyc-NL. Эта система состоит из трех компонен-
тов: словаря, синтаксического анализатора и семантического интерпре-
татора. На данный момент, система Cyc-NL в состоянии обрабатывать
синтаксически сложные и неоднозначные конструкции, включающие в
себя отрицания, модальные и вложенные квантификаторы. Разработ-
чики системы Cyc-NL разрабатывают программный интерфейс, кото-
рый позволит получить доступ к системе Cyc-NL из других систем.
Для получения детальной информации о системе Cyc-NL необходимо
обратиться к [10].
К сожалению, литературы по проекту Cyc на русском языке совсем
немного. Можно упомянуть разве что вводную статью М. Алексеевой
([1]). В данной главе автор пытается заполнить этот пробел, предоста-
вив русскоязычному читателю подробный обзор проекта Cyc на родном
языке. В обзоре на уделено достаточного внимания системе обработ-
ки естественных языков Cyc-NL. Автор посчитал, что необходимо дать
больше информации о проектах, непосредственно касающихся предме-
та изложения данной книги. Проблемы, решаемые системой Cyc-NL,
хотя и достаточно интересные, напрямую с вопросами построения ин-
женерных онтологий не связаны.
Ниже будет приведен обзор онтологий верхнего уровня проекта Cyc,
языка CycL и проекта OpenCyc. Автор надеется, что этой информации
будет достаточно, чтобы породить у читателя интерес к системе.
197
5.2 Язык CycL
CycL представляет собой язык, использующийся в проекте Cyc для опи-

сания онтологий. CycL— формальный язык, т.е. язык, синтаксические
конструкции которого точно описаны и имеют однозначное истолко-
вание. Синтаксис язык базируется на двух источниках: языке логики
предикатов первого порядка ([2]) и функциональном языке LISP ([12]).
Однако, семантика языка CycL, как мы увидим в дальнейшем, отлича-
ется от семантики языка логики предикатов.
Словарь языка CycL состоит из термов (terms). Множество тер-
мов содержит констант составных термов
(constants), (non-atomic
terms (NATs)), переменных (variables) и нескольких других типов
объектов. Термы составляют семантически значимые выражения
(expressions) языка CycL, которые используются для выражения суж-
дений (assertions) в базах знаний проекта Cyc.
Ниже мы рассмотрим основные элементы языка CycL, в большей
степени уделяя внимание наиболее часто использующимся конструкци-
ям. Для более детальной информации о языке заинтересованный чита-
тель может обратиться к Руководству по языку CycL на сайте проекта
([9]). Автор основывает свое изложение свойств языка на этом доку-
менте.
Константы
Константы представляют собой элементы словаря базы знаний про-
екта Cyc. Разработчики проекта пытаются моделировать человече-
ское восприятие мира, поэтому каждая константа обозначает неко-
торую вещь или понятие. Некоторые константы обозначают коллек-
ции других понятий, такие константы так и называются— Коллекции
(Collections). Например, константа #$AnimalWalkingProcess означа-
ет множество действий, производимых животным во время ходьбы,
а константа #$Typewriter означает множество всех пишущих маши-
нок. Другие константы обозначают конкретные объекты, которые мо-
гут более или менее постоянно находится в базе знаний (например,
#$InternalRevenueService— Налоговое Управление США), или возни-
кают там время от времени (например, #$Walking00036— конкретный
случай описания процесса ходьбы). Некоторые константы обозначают
предикаты, такие как #$isa или #$likesAsFriend, использующиеся для
обозначения связей между объектами, другие константы обозначают
функции (функция #$GovernmentFn, получающая в качестве аргумен-
тов константы или другие объекты языка и генерирующая в результате
198
новое понятие— #$GovernmentOf #$Canada). Каждая константа имеет
в базе знаний Cyc свою собственную структуру данных, содержащую,
кроме всего прочего, имя данной константы и множество суждений о
ней.
Большинство констант идентифицируются в языке CycL уникаль-
ными именами Однако, как мы увидим ниже, некоторые константы
могут не иметь постоянных имен. Имена таких констант формируются
как результат выполнения функции, т.е. имя представляет собой со-
ставное выражение. Этот способ именования мы подробно рассмотрим
в дальнейшем. Имена констант должны начинаться с префикса «#$»
(произносится как «хэш-доллар»— hash-dollar).
За префиксом должны следовать по крайней мере два символа име-
ни константы. Иначе говоря, длина имени константы не может быть
менее четырех символов (включая префикс). Для именования констант
позволено использовать буквы верхнего и нижнего регистров, цифры,
дефис «-», подчеркивание «_» и вопросительный знак «?». Имена, раз-
личающиеся только регистром символов, различаются, т.е. язык CycL
чувствителен к регистру (case sensitive).
Все имена предикатов должны начинаться со строчной буквы, а
имена других элементов языка,— либо с прописной буквы, либо с циф-
ры. Внимательный читатель уже, вероятно, заметил соглашение об
именовании констант, применяющееся в языке CycL. Для выделения
значимых элементов имени используются символы верхнего регистра.
Иначе говоря, имя константы состоит из значимых слов, начала кото-
рых выделяются прописными буквами. Например, если мы хотим ис-
пользовать константу для обозначения автора романа «Морской волк»
([3]), то она должна иметь вид #$JackLondon, но не #$Jacklondon или
#$Jack?London. Символы подчеркивания, дефиса и вопросительного
знака нужно использовать для разделения семантически разнородных
компнонентов имени. Например, в имени #$Fruit-TheWord разделены
компоненты «Fruit» (фрукт) и «TheWord» (слово), чтобы отделить обо-
значение имени объекта (фрукт) от его характеристики (слово).
Сами по себе, имена ничего не значат в языке CycL. Совершенно
неважно, каким именно именем будет обозначаться понятие «зеленый
цвет»: #$Green или #$GreenColor. Значение константы определяется
не его именем, а суждениями, которые имеются в системе относитель-
но данной константы. Конечно, будет проще и понятнее использовать
имена, по смыслу согласующиеся с их значениями в базе знаний Cyc,
в противном случае можно внести путаницу. Например, если исполь-
зовать имя #$Green для обозначения цвета, которые в суждениях ба-
зы знаний Cyc обозначает понятие «красный цвет». Но, всегда следует
199
помнить, что смысл константы определяется не его именем, а суждени-
ями относительно этой константы, содержащимися в базе знаний Cyc.
Например:
(#$isa #$Green #$Color)

(#$colorOfObject #$Grass37 #$Green)
(#$forAll ?O (#$implies (#$isa ?O #$Okra)
(#$colorOfObject ?O #$Green)))
Здесь имеются три суждения относительно константы #$Green:
1. #$Green— это цвет.
2. Цвет объекта #$Grass37 (конкретный экземпляр понятия «тра-

ва»)— это #$Green.
3. Для всех объектов, имеющих тип «охра» (#$Okra), их цвет должен

быть #$Green.
Переменные
В языке CycL, выражения с квантификаторами могут содержать пере-
менные, которые используются для обозначения констант, идентифика-
торы которых не определены. Имена переменных должны начинаться
со символа «?» и записываться только прописными буквами. Например,
правильно писать «?FOO», но не «FOO» или «?Foo».
Если в формуле используется одна переменная, то для ее имено-
вания обычно используют только один символ, например, «?X». Если
формула содержит несколько переменных, то принято давать им мне-
монические имена. Например,
(#$implies
(#$and
(#$isa ?TRANSFER #$TransferringPossession)
(#$fromPossessor ?TRANSFER ?FROM))
(#$isa ?FROM #$SocialBeing))
Формулы
Формулы в языке CycL объединяют термы в осмысленные выраже-
ния. Ввиду того, что синтаксис CycL унаследован от языка LISP, каж-
дая в формула в языке CycL имеет вид списка. Список представляет
собой последовательность элементов, заключенную в круглые скобки.
200
Например, формула (?A ?B ?C) представляет собой список из трех пе-
ременных. Элементами списка могут быть также и другие формулы,
т.е. другие списки. Например, список (?A (#$isa ?B #$Green ) ?C)—
это формула, содержащая три элемента, причем второй элемент сам яв-
ляется формулой (списком из трех элементов). Понятно, что элементы
вложенной формулы также могут быть формулами и такое вложенное
структурирование может продолжаться сколь угодно долго. В резуль-
тате, можно построить формулу любой сложности. Списочная струк-
тура проста и логична, но трудно читаема. Поэтому, при написании
сложных формул стараются использовать разметку, записывая элемен-
ты списков в отдельных строках и выделяя элементы одного уровня
вложенности одними и теми же отступами.
Элементы списка формулы называются аргументами (arguments).
По соглашению, нумерование элементов списка начинается с нуля, т.е.
на первый аргумент ссылаются, как на ARG0, на второй— как на ARG1
и т.д. В качестве ARG0 могут выступать предикат, логический опера-
тор или квантификатор. Остальными аргументами могут быть термы,
составные термы, переменные, числа, заключенные в двойные кавычки
строки символов английского алфавита или другие формулы.
Для формул в языке CycL определен специальный класс (Collection)
под именем #$CycFormula. Элементами этого класса являются все пра-
вильные формулы, т.е. правильно сформированные синтаксически и
удовлетворяющие всем семантическим ограничениям.
Формулы простейшего вида называются атомарными формулами
(atomic formulas). В атомарной формуле в качестве ARG0 выступает
предикат, а остальные аргументы представляют собой термы. Напри-
мер,
(#$likesAsFriend #$DougLenat #$KeithGoolsbey)

(#$skillCapableOf #$LinusVanPelt
#$PlayingAMusicalInstrument
#$performedBy)
(#$colorOfObject ?CAR ?COLOR)
Первые две формулы из примера выше представляют собой базовые
атомарные формулы (ground atomic formulas (GAF)). Базовая атомар-
ная формула содержит в качестве ARG0 имя предиката, а остальные
аргументы представляют собой константы (но не переменные).
201
Предикаты
Абсолютное большинство предикатов в языке CycL имеют фиксиро-
ванное число аргументов. Число аргументов предиката называется
егоместностью (arity) (одноместный предикат, двуместный преди-
кат и т.д.). Необязательные аргументы задавать нельзя, хотя неко-
торые предикаты, такие как #$different, могут иметь переменное
число аргументов. Для предикатов с переменным числом аргментов
в языке CycL имеется специальный класс #$VariableArityRelation.
Предикаты с фиксированным числом аргументов также принадле-
жат своим классам, ограничивающим число аргументов. Например,
все предикаты с двумя аргументами должны быть элементами класса
#$BinaryPredicate. Местность предиката можно также указать непо-
средственно с помощью бинарного предиката #$arity, который берет
имя предиката в качестве первого аргумента и количество его аргумен-
тов в качестве второго. На данный момент, в языке CycL не существует
предикатов с числом аргументов, больше пяти.
Атомарная формула считается правильно построенной
(well-formed), если в качестве ARG0 выступает имя предиката, а
число остальных аргументов совпадает с местностью этого предиката.
Кроме того, типы аргументов формулы обязательно должны совпадать
с типами аргументов предиката, который выступает в качестве Arg0.
Например, предикат #$residesInDwelling определен следующим
образом:
(#$isa #$residesInDwelling #$BinaryPredicate)
(#$arg1Isa #$residesInDwelling #$Animal)
(#$arg2Isa #$residesInDwelling #$ShelterConstruction)
Первая формула объявляет константу #$residesInDwelling элемен-
том класс #$BinaryPredicate, т.е. предикат #$residesInDwelling
объявляется как двуместный. Вторая формула задает тип
первого аргумента (#$Animal). Третья формула задает тип
второго аргумента (#$ShelterConstruction). Формула вида
(#$residesInDwelling #$PottedPlant37) заведомо не является
правильно построенной, т.к. количество аргументов в ней не совпадает
с местностью предиката #$residesInDwelling. Формула
(#$residesInDwelling #$PottedPlant37 #$KarensHouse)
будет правильно построенной только тогда, когда тип константы
#$PottedPlant37 будет #$Animal, а тип константы #$KarensHouse—
#$ShelterConstruction.
202
Из формы определения предикатов в языке CycL становится понят-
но, почему невозможно объявить предикаты с местностью, большей
пяти. Дело в том, что обязательно необходимо определить тип каж-
дого аргумента предиката. Для этого используются предикаты вида
#$arg1Isa, #$arg2Isa и т.д. Таких предикатов в языке CycL всего пять:
от #$arg1Isa до #$arg5Isa. Поэтому, определение предикатов местно-
сти, большей пяти, требует изменения языка CycL.
Кроме того, необходимо задать тип предиката, т.е. его при-
надлежность одному из классов предикатов. В языке CycL, все
предикаты должны принадлежать классу #$Predicate. От этого
класса унаследованы классы #$UnaryPredicate, #$BinaryPredicate,
#$TernaryPredicate, #$QuaternaryPredicate и #$QuintaryPredicate,
определяющие одноместные, двуместные, трехместные, четырехмест-
ные и пятиместные предикаты, соответственно. Из этого также следует,
что определение предиката с местностью, большей пяти, синтаксически
невозможно.
Логические операторы
Сложные формулы строятся из атомарных или других сложных фор-
мул с помощью логических операторов (logical connectives). Логиче-
ские операторы представляют собой строго определенный набор кон-
стант, имена которых совпадают с названиями логических операторов,
которые используются в логических языках. Наиболее часто исполь-
зующиеся логические операторы— это #$not, #$and, #$or и #$implies.
Рассмотрим эти операторы подробнее.
Оператор #$not
Оператор #$not эквивалентен логическому отрицанию. В формуле
оператор #$not всегда выступает как Arg0 и имеет один аргу-
мент— формулу, возвращающую истину или ложь. Если аргумент
есть истина, то оператор возвращает ложь, и наоборот. Например,
формула (#$not (#$colorOfObject #$FredsBike #$RedColor))
является истинной, только, если формула
(#$colorOfObject #$FredsBike #$RedColor) ложна, а форму-
ла (#$not (#$not (#$colorOfObject #$FredsBike #$RedColor)))
возвращает то же значение, что формула
(#$colorOfObject #$FredsBike #$RedColor).
Оператор #$and
203
Этот логический оператор аналогичен оператору конъюнкции, исполь-
зующемуся в математической логике. Но, в отличии от логического «и»,
этот оператор может брать на вход любое число аргументов, один, два
и более. Оператор возвращает истину только, если все аргументы ис-
тинны. Например,
(#$and
(#$colorOfObject #$FredsBike #$RedColor)
(#$objectFoundInLocation #$FredsBike #$FredsGarage))
возвращает истину только в том случае, когда мотоцикл Фре-
да красного цвета ((#$colorOfObject #$FredsBike #$RedColor))
и Фред держит этот мотоцикл в гараже
((#$objectFoundInLocation #$FredsBike #$FredsGarage)).
Оператор #$or
Оператор #$or также берет на вход один и более аргументов. Также,
как и логический оператор «или», оператор #$or возвращает истину,
если хотя бы одни из его аргументов является истинным. Рассмотрим,
например, формулу
(#$or
(#$colorOfObject #$FredsBike #$RedColor)
(#$objectFoundInLocation #$FredsBike #$FredsGarage)
(#$owns #$Fred #$FredsBike))
Данная формула возвращает истину, если хотя бы одно из выска-
зываний «мотоцикл Фреда красного цвета», «Фред держит мотоцикл в
гараже» и «Фред— владелец своего мотоцикла» истинно. Могут быть
истины более одной формулы, в этом случае оператор #$or все равно
возвращает истину.
Оператор #$implies
Оператор #$implies аналогичен логической импликации (⇒). Также,
как оператор импликации, оператор #$implies имеет в точности два
аргумента. Аргумент Arg1 является логической посылкой, а аргумент
Arg2— логическим следствием. Логически формула (#$implies A B)
эквивалента (𝐴 ⇒ 𝐵 ) и читается так: «если 𝐴, то 𝐵 ». Оператор возвра-
щает ложь только в том случае, когда первый аргумент есть истина, а
второй аргумент есть ложь. Например, формула
(#$implies
204
(#$owns #$Fred #$Bike001)
(#$colorOfObject #$Bike001 #$RedColor))
возвращает ложь только тогда, когда Фред является собственником мо-
тоцикла не красного цвета.
Суждения с оператором #$implies часто используются в языке
CycL. Такие суждения еще называют условиями(conditionals) илипра-
вилами (rules). Следует также заметить, что формулы, подобные той,
что приведена в примере выше, не часто встречаются в базе знаний Cyc.
Более репрезентативные примеры применения оператора #$implies бу-
дут даны ниже.
Корректность формул с логическими операторами

Формула с логическими операторами является правильной
(well-formed), если все формулы, выступающие в качестве аргу-
ментов, являются правильными, и число аргументов логического
оператора совпадает с разрешенным. Предположим, что A и B—
правильные формулы, а формула C— нет. Тогда, формулы
(#$not A)
(#$and A)
(#$and A B)
(#$or A)
(#$or A B)
(#$implies A B)
правильные, а формулы
(#$not A B)
(#$and)
(#$and A C)
(#$implies A)
не правильные. Читателю предлагает оценить, почему формулы, при-
веденные в примере выше, являются не правильными, самостоятельно
в качестве упражнения.
Квантификаторы
До сих пор мы рассматривали только суждения о конкретных объек-
тах, таких как #$FredsBike. Но, язык CycL, как и всякое исчисление
предикатов первого порядка, позволяет говорить об объектах в общем,
205
не определяя в формуле их конкретные имена. Формулы такого типа
выглядят как высказывания, начинающиеся с «существует объект, для
которого истина формула...» или «для любого объекта выполняется...».
Такие формулы используют так называемые операторы квантифика-
ции уни-
(quantifications). В языке CycL есть два вида квантификации:
версальная квантификация квантификация
(universal quantification) и
существования (existential quantification). Универсальная квантифика-
ция соответствует русским суждениям «для любого» или «для всех», а
квантификация существования— суждениям вида «существует», «най-
дется», «какой-то», «где-то» и т.п.
Язык CycL содержит один оператор универсальной квантифи-
кации (универсальный квантификатор) #$forAll и четыре опера-
тора квантификации существования (квантификатора существова-
ния): #$thereExists, #$thereExistAtLeast, #$thereExistAtMost и
#$thereExistExactly. Рассмотрим эти операторы подробнее.
Универсальный квантификатор #$forAll

Оператор #$forAll имеет два аргумента: переменную и формулу, в ко-
торой эта переменная содержится. На практике, формула обычно пред-
ставляет собой некоторое условие
, в котором посылка используется для
того, чтобы ограничить область применения переменной. Например,
формула
(#$forAll ?X
(#$implies
(#$owns #$Fred ?X)
(#$objectFoundInLocation ?X #$FredsHouse)))
говорит о том, что для любого объекта в онтологии, собственником ко-
торого является Фред, этот объект должен располагаться в доме Фреда.
Квантификация по нескольким переменным

Для квантификации по нескольким переменным можно использовать
вложенные друг в друга формулы с квантификаторами. Например,
формула
(#$forAll ?X
(#$forAll ?Y
(#$implies
(#$and
(#$owns #$Fred ?X)
206
(#$owns #$Fred ?Y))
(#$near ?X ?Y))))
говорит о том, что любые два объекта, находящиеся в собственности
Фреда, должны находиться рядом друг с другом.
Необходимо также отметить, что имена переменных, использующих-
ся в множественной квантификации, не должны совпадать. Иначе го-
воря, не позволяются формулы вида:
(#$forAll ?X
(#$forAll ?X
(#$implies
(#$and
(#$owns #$Fred ?X)
(#$owns #$Fred ?X))
(#$near ?X ?X))))
Свободные переменные
Обычно, если переменная появляется в формуле, то она присутствует в
операторе квантификации, как это было продемонстрировано в приме-
рах выше. Такие переменные называются связанными (bound). Каждая
переменная связана со своим квантификатором и каждый квантифика-
тор связан в точности с одной переменной. Поэтому, применение связан-
ной переменной где-то вне данной формулы бессмысленно. Язык CycL
позволяет использование в формулах свободных(unbound) переменных
(т.е. переменных, которые не связаны ни с каким квантификатором),
но такие переменные все равно трактуются как связанные оператором
универсальной квантификации. Например, формула
(#$implies
(#$owns #$Fred ?X)
(#$objectFoundInLocation ?X #$FredsHouse))
имеет в точности ту же интерпретацию, что и формула
(#$forAll ?X
(#$implies
(#$owns #$Fred ?X)
(#$objectFoundInLocation ?X #$FredsHouse)))
Ввиду того, что формулы со свободными переменными выглядят яс-
нее и проще, оператор #$forAll используется редко. Но, следует иметь
207
в виду, что использование свободных переменных не в условных фор-
мулах, или в условиях, но не в посылке, может привести к непредстка-
зуемым последствиями. Например, формула
(#$implies
(#$owns #$Fred ?WHATEBER)
(#$objectFoundInLocation ?WHATEVER #$FredsHouse))
является истинной для любого объекта в онтологии. Формула, факти-
чески, говорит о том, что любая вещь, собственником которой является
Фред, находится в доме Фреда, а это, конечно, в общем случае неверно.
Квантификатор существования #$thereExists

Квантификатор #$thereExists имеет два аргумента: переменную и
формулу, в которой эта переменная содержится. На практике, данный
квантификатор используется довольно специфически:
(#$implies
(#$isa ?A #$Animal)
(#$thereExists ?M
(#$mother ?A ?M)))
Данная формула говорит о том, что всякий экземпляр класса «Жи-
вотное» (#$Animal), должен иметь мать. Представляющий мать объект
может уже иметься в онтологии в качестве константы, а может быть
новым объектом, о котором Cyc еще не знает.
Квантификаторы #$thereExistAtLeast, #$thereExistAtMost и

#$thereExistExactly
Эти три оператора подобны квантификатору #$thereExists, но предо-
ставляют большие выразительные возможности. Каждый из операто-
ров имеет три аргумента: положительное целое число, переменную и
формулу, содержащую эту переменную. Смысл операторов проще по-
нять на примерах:
(#$implies
(#$isa ?P #$Person)
(#$thereExistExactly 2 ?LEG
(#$and
(#$isa ?LEG #$Leg)
(#$anatomicalParts ?P ?LEG))))
208
Здесь говориться, что каждая персона имеет в точности две ноги3 .
(#$implies
(#$isa ?T #$Table)
(#$thereExistAtLeast 3 ?LEG
(#$and
(#$isa ?LEG #$Leg)
(#$anatomicalParts ?T ?LEG))))
Данная формула содержит суждение о том, что каждый стол должен
имеет по крайней мере три ноги4 . И, наконец, формула
(#$implies
(#$isa ?P #$Person)
(#$thereExistAtMost 1 ?SPOUSE
(#$spouse ?P ?SPOUSE)))
говорит о том, что каждая персона имеет не более одного супруга5 .
Сколемизация
Хотя, суждения с кванторами существования широко используются в
онтологиях Cyc, при просмотре этих онтологий суждений такого ви-
да не показывается. Это происходит из-за того, что система Cyc авто-
матически преобразовывает каждую формулу, содержащую кванторы
существования в сколемовскую нормальную форму6 . Рассмотрим при-
мер. Формула
3 Это, конечно, не верно в общем случае. Есть люди, которые потеряли ноги
в результате несчастных случаев. Есть также люди, которые родились без ног в
результате генетической аномалии. В последнем случае, конечно, можно еще подис-
кутировать, можно ли называть такую персону человеком.
4 Автору приходилось видеть столы с одной, вкопанной в землю, ногой. Веро-
ятно, количество ног у стола (и вообще, наличие ног), не является существенным
признаком понятия «стол».
5 Это также, конечно, не верно. Особенно, в наш бурный век, стремительно ме-
няющий общественные отношения.
6 Приведение высказываний в сколемовскую нормальную форму необходимо
для работы алгоритма логического вывода методом резолюций (см. [11]). Ско-
лемовская нормальная форма представляет собой суждение, содержащее только
операторы конъюнкции и не содержащее кванторов существования. Существу-
ет алгоритм (см. [11] гл. 4 пар. 4.2) автоматического преобразования любого
суждения в сколемовскую форму. Для перехода формула сначала приводится к
конъюнктивному виду, для чего используются законы Де Моргана. После это-
го, первая переменная, связанная квантором существования, заменяется на неко-
торую константу и все вхождения этой переменной в формуле заменяются на
эту константу. Вхождения второй и последующих связанных квантором существо-
209
(#$implies
(#$isa ?A #$Animal)
(#$thereExists ?M
(#$and (#$mother ?A ?M)
(#$isa ?M #$FemaleAnimal))))
будет преобразована к виду
(#$isa #$SKF-8675309 #$SkolemFunction)

(#$arity #$SKF-8675309 1)
(#$implies
(#$isa ?A #$Animal)
(#$mother ?A (#$SKF-8675309 ?A)))
(#$implies
(#$isa ?A #$Animal)
(#$isa (#$SKF-8675309 ?A) #$FemaleAnimal))
Здесь все вхождения переменной ?M заменены на автоматически сгене-
рированную сколемовскую функцию (#$SKF-8675309 ?A).
Составные термы
Составные термы (non-atomic term (NAT)) представляют собой спо-
соб определения терма как функции от других термов. Составной
терм представляет собой функцию, в которой другие термы выступа-
ют в качестве аргументов. Рассмотрим, например, функцию #$FruitFn
(фрукт), которая берет аргумент типа «растение» (plant) и возвраща-
ет класс Фрукт (коллекцию всех фруктов) для переданного объекта
растения. Эту фукнцию можно использовать для определения термов
следующего вида:
(#$FruitFn #$AppleTree)
(#$FruitFn #$PearTree)
(#$FruitFn #$WatermelonPlant)
вания переменных заменяются на функции от тех переменных, которые встре-
тились в исходной формуле до вхождения данной переменной в формулу. На-
пример, формула (∃𝑥)(∀𝑦)(∀𝑧)(∃𝑢)(∀𝑣)(∃𝑤)𝑃 (𝑥, 𝑦, 𝑧, 𝑢, 𝑣, 𝑤) преобразуется к виду
(∀𝑦)(∀𝑧)(∀𝑣)𝑃 (𝑎, 𝑦, 𝑧, 𝑓 (𝑦, 𝑧), 𝑣, 𝑔(𝑦, 𝑧, 𝑣)). Константы и функции, используемые для
замены переменных квантора существования, называются сколемовскими функци-
ями. В языке CycL первое вхождение переменной также заменяется на функцию,
замена на константу не используется.
210
В онтологии может иметься, а может и не иметься, именованная кон-
станта для коллекции фруктов (например, с именем #$Apple (яблоко)
для растения #$AppleTree (яблоневое дерево). Иначе говоря, состав-
ные термы позволяют говорить о типах, даже если таковые не имеют
именованных констант в онтологии.
Составные термы могут использоваться в формулах вместо кон-
стант. Например:
(#$implies
(#$isa ?APPLE (#$FruitFn #$AppleTree))
(#$colorOfObject ?APPLE #$RedColor))
Функции
Ввиду того, что построение составных термов производится с помощью
функций, представляется полезным подробнее ознакомиться с ними.
Также, как и предикаты, большинство функций имеют фиксированное
число аргументов. Можно определять функции с числом аргументов
от одного до пяти. Функции с числом аргументов больше пяти в языке
CycL определять нельзя. В CycL имеются функции с переменным чис-
лом аргументов. Например, функция сложения #$PlusFn имеет пере-
менное число аргументов. Например, составной терм (#$PlusFn 2 3 4)
означает число 9, а (#$PlusFn 12 1)— число 13.
Функции с фиксированным числом аргументов определяются так-
же, как предикаты. Типы аргументов задаются с помощью предика-
тов вида #$arg1Isa, #$arg2Isa и т.д. Если функция имеет нефикси-
рованное число аргументов, то все ее аргументы должны иметь один
и тот же тип, который задается с помощью предиката #$argsIsa.
В отличие от предикатов, функции возвращаются некоторый терм в
качестве результата, тип этого терма задается посредством предика-
та #$resultIsa. Рассмотрим, например, как определяется функция
#$GovernmentFn (правительство):
(#$arity #$GovernmentFn 1)
(#$arg1Isa #$GovernmentFn #$GeopoliticalEntity)
(#$resultIsa #$GovernmentFn #$RegionalGovernment)
Здесь сначала задается число аргументов функции, затем определяют-
ся тип единственного аргумента, как #$GeopoliticalEntity (геополи-
тический субъект) и тип результата как #$RegionalGovernment (реги-
ональное правительство).
211
Функцию #$GovernmentFn можно использовать в любой формуле,
где в качестве параметра выступает тип #$RegionalGovernment. На-
пример, формула
(#$isa (#$GovernmentFn #$UnitedStatesOfAmerica)

#$RegionalGovernment)
обязательно должна быть истинной, так как терм
(#$GovernmentFn #$UnitedStatesOfAmerica) (правительство
США) обязательно должен являться экземпляром класса
#$RegionalGovernment.
Большинство функций являются экземплярами классов7
#$IndividualDenotingFunction (функция, обозначающая идни-
видуальный объект) и #$CollectionDenotingFunction (функция,
обозначающая коллекцию). Функция #$GovernmentFn из примера
выше является экземпляром класса #$IndividualDenotingFunction
т.к. составной терм (#$GovernmentFn #$UnitedStatesOfAmerica)
обозначает единственное правительство, а не коллекцию правительств.
С другой стороны, определенная выше функция #$FruitFn является
экземпляром класса #$CollectionDenotingFunction ввиду того, что
составной терм (#$FruitFn #$AppleTree) обозначает коллекцию всех
яблок яблоневого дерева8 .
Для функций-элементов класса #$CollectionDenotingFunction
необходимо, кроме типов аргументов и результата, определить еще
класс, который будет являть суперклассом (родительским классом)
каждого результата данной функции. Ввиду того, что каждая такая
функция возвращает коллекцию объектов (т.е. класс), составной терм,
задаваемый этой функцией, порождает новый класс в базе знаний Cyc
и его необходимо встроить в онтологию Cyc. Для этого, необходимо
определить данный класс как подкласс какого-то существующего в он-
тологии класса. Делается это с помощью предиката #$resultGenl9 . Это
двуместный предикат, первым аргументов которого является функ-
ция, а вторым— суперкласс класса результата. Например, функцию
#$LeftPairMemberFn (левый элемент пары обуви) можно определить
следующим образом:
7 В терминологии языка CycL классы называются коллекциями (collections). Ав-
тор посчитал удобным для читателя использовать более привычное название «клас-
сы».
8 Об индивидуальных объектах и коллекциях мы подробнее поговорим ниже
9 Genl— это сокращение английского «general» (общий). Иначе говоря, термин
обозначает обобщение некоторого понятия. Таким образом, данный предикат можно
прочитать как «обобщение класса, возвращаемого функцией в качестве результата».
212
(#$isa #$LeftPairMemberFn #$CollectionDenotingFunction)
(#$arity #$LeftPairMemberFn 1)
(#$arg1Isa #$LeftPairMemberFn #$SymmetricalPartType)
(#$resultIsa #$LeftPairMemberFn #$ExistingObjectType)
(#$resultGenl #$LeftPairMemberFn #$LeftObject)
Здесь в качестве родительского класса каждой коллекции, возвраща-
емой функцией #$LeftPairMemberFn, выступает класс #$LeftObject.
Родительские классы следует отличать от типов результата функ-
ции. Любой класс, возвращаемый функцией-экземпляром класса
#$CollectionDenotingFunction, сам является экземпляром класса, за-
данного как тип результата данной функции. В примере выше каж-
дый результат функции #$LeftPairMemberFn есть экземпляр коллек-
ции #$ExistingObjectType.
Напрямую отношения класс-экземпляр и класс-суперкласс задают-
ся предикатами #$isa и #$genls, соответственно. Об отношениях, за-
даваемых на объектах онтологии Cyc, мы поговорим подробно ниже.
Функции материализации
В Cyc часто используются функции-экземпляры класса
#$ReifiableFunction. Каждый раз, когда такая функция вызывается
с новым набором аргументов, в онтологию Cyc добавляется составной
терм, построенный этой функцией с данным набором аргументов, т.е.
составной терм «материализуется» (reified). Материализация означает
резервирование места под данный терм в онтологии Cyc. Позже, если
пользователь пожелает, на это место можно будет сослаться с помощью
константы, но пока для ссылки на терм используется данная функция
с данным набором аргументов.
При материализации терма создается следующее отношение:
(#$termOfUnit NAT-CONSTANT NAT-EXPRESSION)

Здесь NAT-CONSTANT означает константу, используемую для обозначе-
ния терма, а NAT-EXPRESSION означает составной терм, используемый
для материализации данного терма. Интересно, что для функций-эк-
земпляров класса #$ReifiableFunction оба аргумента часто совпада-
ют, хотя означают разные вещи. Например,
(#$termOfUnit (#$GovernmentFn #$Canada)

(#$GovernmentFn #$Canada))
213
Первый аргумент— это константа (#$GovernmentFn #$Canada),
выглядящая как составной терм, а второй аргумент
(#$GovernmentFn #$Canada)— это уже составной терм, использу-
щийся для создания данной константы.
Вероятно, требуется некоторое время, чтобы усвоить это раз-
личие. Наверное, лучше сказать проще: для именования состав-
ных термов, материализуемых вызовами функций-экземпляров клас-
са #$ReifiableFunction, система Cyc использует строку, представля-
ющую собой запись составного терма, использованного для материали-
зации.
Материализованный таким образом терм можно потом как-нибудь
назвать. Для этого используется все тот-же предикат #$termOfUnit.
Например,
(#$termOfUnit #$TheYear1996 (#$YearFn 1996))

(#$termOfUnit #$Apple (#$FruitFn #$AppleTree))
Все сколемовские функции являются функциями материализации.
Контрпримером функции материализации являет функция #$PlusFn.
Эта функция не материализует термов в онтологии Cyc, т.к. резуль-
тат вызова этой функции есть число, представляющее сумму ее аргу-
ментов. На это число можно сослаться напрямую, поэтому надобности
материализовывать терм не имеется. Другим контрпримером является
функция #$UnitOfMeasure (единица измерения).
Квантификация в составных термах

Если функция представляет собой экземпляр класса
#$ReifiableFunction, то составные термы, порождаемые этой
функцией, можно использовать в выражениях квантификации. Это
бывает полезно, когда в правилах имеются составные термы, в которые
в качестве одного или нескольких аргументов передается переменная.
Квантификацию в составных термах можно проводить одним из
следующих способов:
1. Можно использовать переменные ?ARG1, ?ARG2, ?ARG3 и т.д.

для обозначения аргументов функции.
2. Ввести свободную переменную для обозначения результата функ-

ции данного составного терма.
214
3. Добавить в посылку правила суждение с предикатом #$equals с
тем, чтобы сказать системе Cyc, что данная переменная является
составным термом.
Приведем пример с использованием последнего способа:
(#$implies
(#$and
(#$equals ?U (#$PreviouslyOwnedFn ?ARG1))
(#$isa ?X ?U))
(#$hasAttributes ?X #$Used))
Суждения
До сих пор описывался исключительно синтаксис языка CycL. Этот
синтаксис может быть использован различными внешними приложени-
ями, чтобы добавлять новые суждения в базу знаний системы Cyc или
отправлять запросы к ее онтологии. Сейчас сосредоточим свое внима-
ние на структуре онтологии Cyc.
Онтология Cyc состоит из большого множества суждений. Когда
формула добавляется в онтологию (это происходит только тогда, ко-
гда формула правильно простроена), то она добавляется как одно или
несколько суждений. С суждениями связаны следующие элементы:
∙ Формулы.
∙ Микротеории.
∙ Истинностные значения.
∙ Направления (directions).
∙ Основания (supports).
Рассмотрим каждый из этих элементов подробнее.
Формулы
Формулы представляют собой выражения на формальном языке, ис-
пользующиеся для определения суждений о мире. В этом смысле, фор-
мулы представляют собой аналог повествовательных предложений рус-
ского языка. Правильно построенные формулы в языке CycL называ-
ются Cyc-формулами (CycFormulas). Основным объектом изучения в
разделе, посвященном синтаксису языка CycL, были формулы.
215
Микротеории
Каждое суждение содержится по крайней мере в одной микротеории.
Если это необходимо, суждение может содержаться сразу в несколь-
ких микротеориях. Имеются даже суждения, которые содержаться в
каждой микротеории. Наибольшее число суждения содержится в мик-
ротеории под названием #$BaseKB.
Микротеории являются экземплярами класса #$Microtheory и, как
и между любыми классами онтологии Cyc, между микротеориями мож-
но устанавливать отношения вида класс-подкласс (отношение обоще-
ния в терминологии Cyc). Если суждение принадлежит некоторой мик-
ротеории, то это суждение также должно принадлежать и всем микро-
теориям, представляющим собой подклассы данной микротеории. Мик-
ротеории также называются контекстами . Для детальной информа-
ции о контекстах см. [6].
Истинностные значения
К каждому суждения присоединено истинностное значение, показыва-
ющее «степень истинности» этого суждения. Для выражения степени
истинности суждений в CycL используется пять возможных истинност-
ных значений. Наиболее часто из них используются два:
∙ Постоянно истинные (monotonically true) суждения являются ана-

логом тавтологий в логических исчислениях. Такие суждения
должны быть истинными всегда, т.е. для всех констант, заменяю-
щих универсально квантифицированные переменные в этих суж-
дениях. Если, при каком-то наборе констант, суждение становится
ложным, то система генерирует ошибку.
∙ Истинные по умолчанию (default true) суждения, в отличии от

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

предикатов #$isa и #$genls, являются постоянно истинными, а все
остальные суждения, включая правила,— истинными по умолчанию.
216
Направления
Направление (direction) представляет собой привязываемое к каждому
суждению значение, которое задает, в каком сорте логического выво-
да данное суждение будет задействовано. Существует три значения для
направления: прямое (forward), обратное (back) и код (code). Процедура
логического вывода задействует суждения с прямыми направлениями,
когда добавляет суждения в базу знаний Cyc, а суждения с обратны-
ми направлениями— - когда строит запросы к базе знаний, причем эти
запросы строятся с помощью процедуры обратного вывода (backward
inference). По умолчанию, все базовые атомарные формулы имеют пря-
мое направление, а правила— обратное.
Суждения, направление для которых имеет значение «код», вообще
не используются в обычных процедурах логического вывода. В системе
Cyc имеется возможность добавлять в систему пользовательские моду-
ли логического вывода— так называемые модули эвристического уров-
ня (heuristic level (HL))10 . Если суждение имеет направление «код», то
оно задействуется только при работе соответствующего модуля.
Основания
Основания (supports) представляют собой один из видов обоснований
(justification) суждения. Обоснования говорят о том, почему
данное
суждение имеет то или иное истинностное значение. В этом смысле,
обоснования похожи на аргументы защиты или обвинения в судебном
процессе. Основания говорят о том, каким образом данное суждение
попало в онтологию. В абсолютном большинстве случаев, основание
суждения имеет значение «локальное» (local), которое показывает, что
данное суждение было добавлено в базу знаний из внешнего источника
(обычно, это KEer11 ). Иногда, основания имеют значения «источник»
(source), показывающее, что суждение было добавлено в онтологию в
результате работы процедуры логического вывода.
10 В системе Cyc имеются также модули эпистемологического уровня

(epistemological level (EL)). Эти модули используются для представления зна-
ний пользователям и при взаимодействии с другими программами
11 KEer представляет собой сокращение от Knowledge Enterer— персоны, осу-
ществляющей добавление знаний в онтологию Cyc.
217
5.3 Система логического вывода
Система логического вывода Cyc (Cyc Inference Engine) поддерживает

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

В предыдущих версиях Cyc, формулы хранились в том же виде, в каком
они вводились пользователями системы. Например:
(implies
(and
(isa ?afp AdultFemalePerson)
(residesInRegion ?afp Guam))
(and
(acquaintedWith Zippy ?afp)
(likesAsFriend Zippy ?afp)))
В Cyc-10 формулы сохраняются в конъюнктивной нормальной фор-
13
ме . Когда формула добавляется в онтологию Cyc, она автоматически
12 Модус поненс или правило отделения позволяет осуществлять вывод следую-
щим образом: если в онтологии имеются формулы 𝐴 и 𝐴 ⇒ 𝐵 , то в онтологию
также можно добавить и формулу 𝐵 . Модус толленс представляет собой обращение
правила модус поненс: если в онтологии имеются формулы ¬𝐵 (отрицание 𝐵 ) и
𝐴 ⇒ 𝐵 , то можно также добавить и формулу ¬𝐴.
13 Говорят, что формула 𝐹 находится в конъюнктивной нормальной форме, если
она имеет вид 𝐹 = 𝐹1 ∧ 𝐹2 ∧ . . . ∧ 𝐹𝑛 , где каждая из формул 𝐹1 , . . . 𝐹𝑛 представляет
218
преобразуется в конъюнктивную нормальную форму. За это ответстве-
нен специальный модуль— канонизатор
(canonicalizer). Вот, как будет
канонизирована формула из примера выше:
(and
(or
(not (isa ?afp AdultFemalePerson))
(not (residesInRegion ?afp Guam))
(acquaintedWith Zippy ?afp))
(or
(not (isa ?afp AdultFemalePerson))
(not (residesInRegion ?afp Guam))
(likesAsFriend Zippy ?afp)))
Универсальная квантификация в Cyc-10 обрабатывается тривиаль-
ным образом: переменные, связанные с квантором всеобщности, счи-
таются свободными. Как уже говорилось выше, формулы, содержащие
кванторы существования, подвергаются сколемизации. Например, фор-
мула
(forAll ?A
(implies
(isa ?A Animal)
(thereExists ?M
(and
(mother ?A ?M)
(isa ?M FemaleAnimal)))))
сначала будет приведена к виду
(implies
(isa ?A Animal)
(and
(mother ?A (SkolemFunctionFn (?A) ?M))
(isa (SkolemFunctionFn (?A) ?M) FemaleAnimal)))
после чего подвергнется сколемизации. В результате, получим формулу
собой дизъюнкцию литералов (см. [11], стр. 23). Под литералом подразумевается
формула, состоящая из единственного предиката, аргументами которого являются
несоставные термы или их отрицания. Фактически, литералы— это базовые атомар-
ные формулы, только расширенные формулами, где в качестве аргументов могут
выступать отрицания термов. Известно, что любое высказывание можно автомати-
чески преобразовать в конъюнктивную нормальную форму.
219
(and
(or
(not (isa ?A Animal))
(mother ?A (SkolemFunctionFn (?A) ?M)))
(or
(not (isa ?A Animal))
(isa (SkolemFunctionFn (?A) ?M) FemaleAnimal)))
Модуль канонизации автоматически генерирует имя для каждой
сколемовской функции, которую ему необходимо создать во время кано-
низации. Это имя позже может быть заменено пользователем на более
осмысленное. Кроме того, канонизатор также описывает свойства ско-
лемовской функции: местность, типы аргументов— совершенно также,
как в случае обычной функции. Вот, например, как после применения
алгоритма сколемизации (канонизации) будет выглядеть в действитель-
ности формула из примера выше:
(and
(or
(isa SKF-8675309 SkolemFunction))
(or
(arity SKF-8675309 1))
(or
(arg1Isa SKF-8675309 Animal))
(or
(resultIsa SKF-8675309 FemaleAnimal))
(or
(not (isa ?U Animal))
(mother ?U (SKF-8675309 ?U)))
(or
(not (isa ?U Animal))
(isa (SKF-8675309 ?U) FemaleAnimal)))
Модуль канонизации также запоминает порядок литералов в добав-
ляемой формуле. Это необходимо для того, чтобы быстро сравнивать
формулы друг с другом во время логического поиска. Если порядок
литералов зафиксирован, то во время поиска можно сосредоточиться
только на структурном сравнении формул.
220
Логический вывод: введение
Обратный логический вывод (backward inferencing) в Cyc— это тип ло-
гического вывода, инициирующийся операцией ASK14 Обратный вывод
можно представлять как поиск по дереву, где каждый узел дерева— это
формула, для которой проверяется связывание которой с переданными
константами, а ребра между узлами представляют собой трансформа-
цию суждения— объекта проверки.
Поясним сказанное на примере. Предположим, проводится поиск
объектов, на которых истинна формула (likesObject ?x ?y). Эта
формула будет корнем дерева в описанной выше процедуре обратного
логического вывода. Для ответа на запрос необходимо найти суждения,
которые помогут связать переменные ?x и ?y с конкретными объектами.
В онтологии может быть формула вида (likesObject Keith BillM). В
этом случае, будет создан дочерний узел корня дерева— это будет про-
сто константа #$True, т.к. предикат likesObject выполняется на кон-
стантах Keith и BillM. Предположим также, что в онтологии имеется
формула вида
(implies
(possesses ?x ?y)
(likesObject ?x ?y))
Тогда, у корня дерева поиска появится второй узел— формула
(possesses ?x ?y). Процедур обратного вывода рекурсивно запустит-
ся на этом узле. Предположим, что в онтологии имеется формула
(implies
(objectFoundInLocation ?x KeithsHouse)
(possesses Keith ?x))
заключение которой совпадает с обрабатываемым узлом дерева. Тогда,
у узла формулы (possesses ?x ?y) появится дочерний узел с форму-
лой (objectFoundInLocation ?x KeithsHouse), у которой второй па-
раметр связан константой KeithsHouse, т.е. у узла имеется только одна
14 Операция ASK (запрос) в Cyc представляет собой одну из двух базовых опера-
ций с базой знаний. Целью операции ASK является опрос базы знаний на предмет
того, является или нет некоторая формула истинной. Вторая базовая операция,
осуществляемая с онтологией Cyc,— это ASSERT (добавление). Операция ASSERT
обычно используется для добавления в базу знаний новых суждений. При добав-
лении используется прямой логический вывод, в отличие от обратного вывода, ис-
пользуемого в операции ASK.
221
свободная переменная. Это можно интепретироваться следующим об-
разом: мы ищем вещи в доме Кейта, потому что, если каккая-то вещь
находится в доме Кейта, то Кейт будет владельцем это вещи, а значит,
эта вещь будет ему нравиться. Вопрос же о том, что нравится Кейту,
есть частный случай проблемы, поставленной вопросом о выполнимо-
сти формулы (likesObject ?x ?y).
Предположим, что в онтологии также имеется правило
(implies
(and
(isa ?x Agent)
(owns ?x ?y))
(possesses ?x ?y))
тогда в дерево будет добавлен новый узел
(and
(isa ?x Agent)
(owns ?x ?y))
Развертывание дерева, очевидно в любом случае, закончится, когда
в узлах не останется свободных переменных, независимо от того, най-
дутся ли в онтологии суждения, которые могут инициировать создание
дочерних узлов данного узла.
Из рассмотренных примеров видно, что алгоритм логического выво-
да, инициированный операцией ASK, фактически, представляет собой
поиск по дереву. Здесь остаются невыясненными следующие вопросы:
1. Каким образом производится решение, какие узлы дерева будут

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

создания новых узлов?
Логический вывод в Cyc

Три наиболее наиболее важных характеристики логического вывода:
1. Код системы логического поиска строится на основе модульного

принципа. Взаимодействие между модулями должно быть тща-
тельно продумано и отлажено.
2. Текущее состояние логического поиска может быть сохранено. По-

этому, поиск может быть продолжен снова даже в том случае, если
222
в какой-то момент он был прекращен из-за недостатка ресурсов
программной системы.
3. Логический поиск полностью параметризован, в качестве пара-

метров могут выступать различные поисковые алгоритмы.
Обсудим чуть подробнее третий пункт. По умолчанию, в Cyc-10 про-
изводится эвристический поиск (о котором подробно поговорим ниже),
но для некоторых целей необходим и полноценный поиск с построе-
нием полного дерева. Такое построение обычно называются поиском в
глубину (depth-search). Поиск в глубину необходим, например, в проце-
дуре прямого логического вывода, для которой необходимо построение
полного дерева. Но, обычно, приложения используют преимущества па-
раметризованного поиска, проводя, в основном, эвристический поиск15 ,
но применяя для некоторых узлов другие методы.
Эвристики для выбора дочернего узла

В системе Cyc-10 используется большое число эвристических правил
для выбора дочернего узла дерева. Большинство из них чисто синтак-
сические:
1. Среди возможных дочерних узлов данного узла дерева поиска вы-
бирается узел с наименьшим числом литералов. Эта эвристика
позволяет управлять скоростью поиска посредством выбора наи-
меньшего поддерева.
2. Выбирается узел с наименьшим числом свободных переменных.

Это также позволяет управлять скоростью поиска, двигаясь каж-
дый раз к дереву с наименьшим количеством ветвей.
3. Редко выбираются узлы, которые уже присутствуют в дереве

где-то наверху. Это позволяет избежать слишком глубокого спус-
ка по дереву с использованием повторяющихся узлов.
4. Узлы без свободных переменных имеются высший приоритет. Ес-

ли в формуле не осталось свободных переменных, то поиск с боль-
шой вероятностью может в недалеком будущем прийти к завер-
шению.
15 Под эвристическим поиском здесь понимается применение специальных проце-
дур, позволяющих на основе каких-то свойств формулы выбрать ее среди остальных
кандидатов для построения следующего узла дерева вывода. Критерии, на основе
которых осуществляется выбор той или иной формулы, называются эвристиками
или эвристическими правилами.
223
5. Редко выбираются узлы, формулы которых содержат отрицания.
База знаний Cyc состоит, в основном, из позитивных (т.е. не со-
держащих отрицания) суждений, поэтому вероятность найти ре-
шение среди позитивных суждений выше.
В поиске используются также семантические эвристические прави-

ла:
1. Отбрасываются узлы, которые могут быть частью цикла при уни-

фикации параметров формулы.
2. Отбрасываются узлы, которые кажутся наименее пригодными

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

Часто формула содержит более одного литерала. В примере выше
встречался узел с формулой
(and
(isa ?x Agent)
(owns ?x ?y))
Если узел с этой формулой был выбран для обработки, то необходимо
решить, какой литерал надо обрабатывать первым: искать элементы
класса Agent или пары, удовлетворяющие предикату owns.
В Cyc-10 используется следующий подход. Литерал передается на
оценку каждому эвристическому модулю (HL module) системы. Мо-
дуль возвращает численную меры стоимости обработки литерала (чем
выше трудность обработки, тем выше цена). Эти меры суммируются
16В оригинальной документации совокупность всех таких весовых правил срав-
нивается с хором, участниками которого выступают сами правила. Каждому оце-
ниваемому узлу «поется песня» и, чем громче звучат «голоса» правил при оценке
данного узла, тем громче песня. Выбирается узел, песня которого была наименее
громкой.
224
и выбирается литерал с наименьшей ценой. Эта процедура похожа на
рассмотренную выше процедуру выбора узла на основе весовых эври-
стик, только в данном случае выбирается литерал для обработки, а не
дочерний узел.
Параметры поиска в Cyc-10

Состояние логического поиска сохраняется в специальной структуре,
поля которой содержат методы, используемые для реализации специ-
фической поисковой методики, и реализованные в виде функций. Пе-
речислим эти функции:
∙ too-deep-func : node depth-cut -> [boolean]. Эта функция

используется для оценки того, вышел или нет данный узел за пре-
делы допустимой глубины дерева поиска.
∙ add-node-func : node leaves -> leaves. Функция использует-

ся для добавления новых узлов в дерево поиска.
∙ no-leaves-p-func : leaves -> [boolean]. Данная функция ис-

пользуется для проверки, имеет или нет данный узел дочерние
узлы. Если таковых нет, то поиск в данной ветке дерева заканчи-
вается.
∙ next-node-func : leaves -> node, leaves. Функция позволяет

выбирать узел для обработки из множества возможных дочерних
узлов.
∙ goal-p-func : node -> [boolean]. Эта функция используется

для определения, удовлетворяет или нет данный узел цели по-
иска.
∙ add-goal-func : node goals -> goals. Если узел является це-

левым узлом поиска, то данная функция добавляет его во множе-
ство целевых узлов.
∙ options-func : node -> [list of options]. Данная функция

предоставляет список опций, использующихся для определения
следующего узла для обработки.
∙ expand-func : node option -> [list of nodes]. Эта функция

используется для задания списка дочерних узлов в дереве поиска,
т.е. тех, которые будут обрабатываться процедурой поиска далее.
225
Данную структуру используют все процедуры поиска: поиск в глу-
бину и эвристический поиск. Для каждой конкретной процедуры поис-
ка поля структуры заполняются конкретными функциями и процедура
поиска параметризуется.
Узлы поиска
В Cyc-10, каждый узел поиска представлен специальной структурой со
следующими полями:
∙ Поле search содержит информацию о том, какая процедура по-

иска инициировала создание данного узла.
∙ Поле parent содержит ссылку на родительский узел.

∙ Поле children представляет собой список ссылок на дочерние уз-
лы.
∙ Поле depth— это глубина узла в дереве поиска.

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

жит описание семантики узла.
Данные о семантике узла содержат следующую информацию:
∙ formula: содержит формулу, которая инициировала порождение

данного узла.
∙ inference supports: суждения и эвристические модули, которые

были использованы для порождения данного узла из родитель-
ского.
∙ variable bindings: соответствие между переменными родитель-

ского узла данного узла и элементами, с которыми данные пере-
менные были связаны, чтобы породить данный узел.
ASK и направления
Как уже говорилось выше, процедуры ASK и ASSERT используют на-
правления (directions) для управления доступом к суждениям во время
логического вывода. Направления могут иметь два значения: прямое
(forward) и обратное (backward). Суждения с прямыми направлениями
226
используются в процедурах ASSERT, а суждения с обратными направ-
лениями— в процедурах ASK.
Обратные базовые атомарные формулы не задействуются во время
добавления суждений в онтологию Cyc, т.е. в процедурах ASSERT. Пря-
мой вывод использует только правила и базовые атомарные формулы с
прямым направлением. Большинство интерфейсов, используемых для
добавления суждений в базу знаний Cyc, по умолчанию полагают, что
каждое правило (формула импликации) имеет обратное направление, а
базовая атомарная формула— прямое.
Эквивалентность
Эквивалентность используется в процедуре унификации. В онтологии
Cyc сравнение элементов основано на положении об уникальности их
имен: элементы с разными именами считаются различными, а элемен-
ты с совпадающими именами— эквивалентными. Кроме того, эквива-
лентными считаются те элементы, о равенстве которых явно сказано в
онтологии. Равенство элементов задается с помощью предиката equals,
например: (equals Fred Joe) задает равенство констант Fred и Joe17 .
Во время унификации не производится никаких процедур вывода, от-
носящихся к проверке эквивалентности элементов.
17 Таким образом, отношение эквивалентности между именами можно сравнить

с отношением синонимии на словах русского языка.
227
5.4 Онтология системы Cyc
Как уже говорилось выше, онтология системы Cyc имеет довольно

сложную и разветвленную структуру. В этом разделе мы рассмотрим
эту структуру более детально.
Авторы системы Cyc предпочитают выводить структуру онтологии
Cyc в виде пирамиды, изображенной на рисунке 5.1. Если взглянуть
Рис. 5.1: Онтология системы Cyc в виде пирамиды.

упрощенно, то эту пирамиду можно представлять как изображение де-
рева таксономии классов (коллекций) базы знаний системы Cyc. Ко-
нечно, система Cyc позволяет, чтобы у класса было более одного су-
перкласса, поэтому на самом деле структура онтологии системы это не
таксономия (дерево), но направленный ациклический граф, т.е. более
сложная структура. Для упрощения изложения, мы, следуя авторам
системы, изобразившим структуру онтологии в виде пирамиды, будем
считать структуру таксономией. Авторы системы предоставили специ-
альное приложение, делающее эту пирамиду интерактивной. Приложе-
ние доступно на странице [8]. Пользователю достаточно кликнуть ле-
вой кнопкой мыши на рисунке пирамиды онтологии и откроется новая
страница браузера с интерактивным приложением.
Внимательный читатель уже наверное заметил, что на пирамиде
онтологии, изображенной на рисунке 5.1, названия элементов отделены
228
друг от друга секторами. Если пользователь кликнет на такой сектор
левой кнопкой мыши, то в окне пирамиды будет выведена информа-
ция об элементе онтологии. Окно приложения разделено на три части.
В центральной части находится интерактивный рисунок пирамиды он-
тологии. В левой части выводится имя элемента онтологии. В нижней
части выводится описание этого элемента. Элементы онтологии разде-
лены на уровни, каждый из которых выделен своим цветом. По мере
обретения конкретики, т.е. спуска (подъема?) по дереву таксономии,
цвет уровней меняет от светло-серого к более темным тонам. Специфи-
ческие для описаний конкретных знаний понятия уже выделены тем-
но-синим цветом. Ниже мы рассмотрим большую часть пирамиды в
подробностях.
Более привычный взгляд на онтологию дается на рисунке 5.2. На
этом рисунке онтологию изображен в виде направленного (хотя направ-
ления ребер не указаны на рисунке, подразумевается, что у каждого
ребра имеется направление, от суперкласса к дочернему классу) ацик-
лического графа.
Рис. 5.2: Онтология системы Cyc в виде ациклического графа.
229
Светло-серый уровень
На этом уровне располагаются самые абстрактные понятия, которые
еще не имеют пространственной и временной протяженности. Рассмот-
рим их.
Понятие Объект (Thing) представляет собой корень дерева таксо-
номии системы Cyc. Каждый элемент онтологии имеет класс Объект
в качестве суперкласса. Поэтому, можно сказать, что каждый элемент
онтологии системы Cyc есть Объект. С точки зрения реализации, поня-
тие Объект представляет собой структуру, содержащую информацию,
позволяющую:
1. Сравнивать элементы таксономии друг с другом.
2. Обращаться к элементам онтологии непосредственно используя

программный интерфейс.
Класс Нематериальный Объект (Intangible Thing) является пря-

мым потомком класса Объект. Нематериальные объекты не имеют ма-
териального воплощения, они не сделаны, не закодированы и т.п. Нема-
териальные объекты— это события, такие как поход в горы или поеда-
ние завтрака. Идеи также являются нематериальными объектами. С
точки зрения реализации, весьма полезно отличать нематериальные
объекты от остальных. Это позволяет избежать различных ошибок,
например, задания вопроса пользователю о том, какого цвета будет со-
брание в следующий четверг.
Другой непосредственный потомок класса Объект— это класс Ин-
дивид (Individual). В Индивидах главное, что они отличаются от Мно-
жеств и Коллекций. Индивидами являются события, физические объек-
ты, числа и отношения. Конкретный автомобиль Тойота Королла— это
Индивид, но понятие «четырехдверный седан»— уже коллекция. Эта
коллекция, в отличие от конкретного автомобиля, абстрактна. Она не
имеет протяжения, массы и максимальной скорости, но имеет элемен-
ты, подколлекции и надколлекции.
Класс Отношение (Relation) является потомком класса Нематери-
альный Объект. Отношения подобны клею, который соединяет разроз-
ненные понятия в суждения. Например, понятия «Иосиф Кобзон» и
«певец» можно связать предложением «Иосиф Кобзон это певец». Свя-
занные отношениями понятия представляют собой суждения . Также,
отношения можно использовать при работе с внешними источниками
знаний, такими как базы данных компаний или Web страницы. Как чи-
татель могу убедиться выше, система Cyc построена на принципе: «чем
230
больше суждений, тем лучше». Создатель системы Дуглас Ленат из-
вестен своим высказыванием: «интеллект— это десять миллионов суж-
дений». Язык CycL представляет собой язык исчисления логики пре-
дикатов первого порядка, но содержит также и много возможностей,
относящихся к языку второго порядка. В частности, отношения так-
же можно связывать друг с другом другими отношениями, что, поми-
мо всего прочего, позволяет системе автоматически обучаться. Когда
в систему добавляется факт о том, что автомобиль X имеет подушку
безопасности, то система Cyc уже знает, что автомобиль X содержит
подушку безопасности, а также все ее составные элементы, внутри ав-
томобиля. Это происходит в результате уже имеющихся связей между
отношениями Содержать Быть Частью Внутри
, и .
Класс Множество(Set) представляет собой прямой аналог понятия
Коллекции
математического множества. В отличие от , элементы мно-
жества не обязательно связаны между собой какими-то общими свой-
ствами. Единственное общее свойство таких элементов— это то, что они
принадлежат данному множеству.
Класс Коллекция(Collection) представляет собой прямой аналог
рассматривавшегося нами в первой главе понятия типа. Все элемен-
ты коллекции имеют нечто общее и это общее выражается посредством
одних и тех же атрибутов. Как уже говорилось выше, главным отли-
чием Коллекций и Множеств от Индивидов является то, что послед-
ние не могут иметь элементов. Коллекции отличаются от Множеств
еще и тем, что могут иметь несколько «воплощений» одновременно,
т.е. могут иметься два экземпляра класса Коллекция, имеющих одни
и те же элементы, но они все равно будут рассматриваться, как раз-
личные. Множества считаются идентичными, если они содержат одни
и те же элементы. Вообще, хорошей коллекцией считается такая, кото-
рую трудно или вообще невозможно определить простым перечислени-
ем элементов. Например, коллекция всех белых автомобилей не очень
хороший пример для создания, так как это понятие легко определить
посредством других элементов системы Cyc и, следовательно, само по-
нятие не очень информативно. С другой стороны, коллекция всех «бе-
лых воротничков»18 очень трудно определима простым перечислением
элементов, поэтому об этом понятии можно многое сказать.
Класс Путь
(Path) представляет собой непересекающийся путь или
цикл. Пути могут представлять пространственно-временные абстрак-
ции (ребра между узлами в графах), нематериальные абстракции рас-
положений (линии географической широты) или вполне конкретные ли-
18 Так называют сословие офисных работников.
231
нии (разделительная полоса на автомобильной трассе). Иначе говоря,
путь может быть всем, что используется как путь в данной системе. На-
пример, апельсин, вообще говоря, это не путь. Но он может стать путем
для муравья в системе управления путями муравьев посредством апель-
синов. Заметим также, что Путь не обязательно является индивидом,
т.к. ничто не мешает использовать множества или коллекции в качестве
путей в специфических системах. Основное разделение путей— это так
называемый Простой Путь (Simple Path), представляющий незамкну-
тые кривые, и Циклический Путь (Cyclic Path), представляющий все
замкнутые контуры.
Хотя понятие Логика (Logic) и не является классом (collection) в он-
тологии Cyc, это понятие является в ней фундаментальным. На логи-
ческих заключениях строятся элемента базы знаний Cyc— так называе-
мые суждения. Вероятно, поэтому авторы поместили описание связан-
ных с логикой понятий на светло-серый уровень. Эти понятия мы уже
подробно рассматривали выше, поэтому нет необходимости повторять
описание здесь. Скажем кратко: в Cyc имеют две логические констан-
ты Истина и Ложь. Суждения строятся из констант и других суждений
с помощью логических связок— операторов конъюнкции, дизъюнкции,
отрицания и импликации. Если суждение выполняется на каком-то на-
боре своих констант, то на нем это суждение считается истинным, в
противном случае— ложным. Кроме того, в Cyc также реализована про-
цедура логического вывода, в деталях описанная выше.
Математические понятия (Mathematical (or computational)
things), не связанные с понятиями нижних уровней (пространственны-
ми, временным или материальными), также располагаются на этом
уровне. Среди таких понятий находятся числа, множества, алгоритмы,
абстрактные символьные строки и т.п.
Умеренно-серый уровень
На этом уровне располагаются понятия, связанные с пространствен-
ными и временными соотношениями, а также связанные с понятием
материи. Некоторые понятия заданы в онтологии Cyc в виде классов
(collections), другие представляют собой целые группы понятий, объ-
единенных сходными признаками. Рассмотрим их.
Класс Пространственный Объект (Spatial Thing) содержит в себе
все понятия, связанные с протяженностью и местоположением. Когда
вводятся понятия этого класса, необходимо обращать внимание на две
вещи. Во-первых, объект класс Пространственный Класс может быть
частично материальным (например, Ленинградская область) или во-
232
все нематериальными (окружность на плоскости). Во-вторых, совсем
необязательно определять местоположение этого объекта относительно
других пространственных объектов, хотя это и можно делать. Дело в
том, что не всякий пространственный объект имеет местоположение.
Например, отрезок на плоскости как геометрическое понятие не имеет
местоположения.
Класс Пространственный Путь (Spatial Path) представляет пути
в пространстве, связывающие пространственные объекты. В качестве
примером пространственных путей можно привести дорогу, коридор,
проволоку, кровяные сосуды и нервы. Следует иметь ввиду, что аб-
страктные пути, такие как генеалогическое древо, не являются Про-
странственными Путями.
Класс Рамка (Border) содержит такие понятия, как линии, отрезки,
плоскости или пространственные области, которые служат границами
(формируют рамки) между двумя Пространственными объектами.
Класс Перемещение (Movement) представляет собой событие, за-
ключающееся в пространственном перемещении. Перемещение может
происходить вдоль некоторого пути, т.е. объект, в этом случае, преодо-
левает некоторую дистанцию, или быть поворотом объекта вдоль неко-
торой оси. Перемещение может быть непрерывным или периодическим.
В качестве примеров перемещений можно привести полет на самолете (с
промежуточными посадками), поедание пищи или электрический ток.
Класс Артефакт (Artifact) представляет собой неодушевленные ве-
щи, произведенные агентами специально для каких-то целей. Для со-
здания артефакта не обязательно создавать для него новый материал,
агент может создать артефакт просто переделав другие вещи. В ка-
честве примеров артефактов можно привести флейту, сделанную из
ветвей дерева, или монету, сделанную из металла путем тиснения. Вдо-
бавок к человеческим артефактам (инструментам, зданиями, докумен-
тами, линиям электропередач) к таковым можно отнести и артефакты,
сделанные животными (гнезда, термитники, бобровые плотины).
В системе Cyc используется более 37 тысяч различных типов Собы-
тий (Events). События используются для описания того, что случилось
в мире. Общие события включаются в себе пение, делание покупок,
мышление (рассматриваемое как событие вида «мыслить что-то») и т.п.
Индивидуальным событием может быть, например, «полет Гагарина в
космос» или «начало Великой Отечественной Войны».
Сценарий (Script) представляет собой описание сложного события,
состоящего из подсобытий, связанных между собой временными отно-
шениями. Приложения могут использовать сценарии для распознава-
ние того, что данное событие является частью более сложного события,
233
описываемого данным сценарием. Сценарии также можно использовать
для планирования и для осуществления процесса чтения.
Класс Временный Объект (Temporal Thing) представляет объекты,
имеющие временную протяженность или расположение во времени. К
объектам этого типа применим вопрос «когда?». Таким образом, к вре-
менным объектам можно отнести множество вещей, например, события,
физические объекты, соглашения, временные интервалы и т.д. Объек-
ты, не имеющие свойства временности, такие как математические мно-
жества, атрибуты или числа, очевидно не являются Временными Объ-
ектами.
Темно-серый уровень
На этом уровне расположены объекты, либо имеющие материальное во-
площение, либо взаимодействующие с такими объектами. Рассмотрим
элементы этого уровня подробнее.
Класс Физический Объект (Physical Object) представляет все объ-
екты, которые состоят из материи и существуют во времени (т.е. к та-
ким объектам можно применять временные категории: когда появился,
как изменился и т.п.). Такие объекты могут содержать, а могут и не со-
держать, нематериальные элементы. Например, конкретный экземпляр
книги представляет собой физический объект, т.к. сделан из материи и
имеет пространственную и временную протяженность (размеры и год
издания). Но, этот объект также имеет содержание, т.е. смысл текста,
напечатанного на страницах этой книги. Содержание, очевидно, явля-
ется нематериальным объектом.
Материалы (Materials) используются для выделение из неодушев-
ленного объекта другого неодушевленного объекта, который был ис-
пользован для создания первого объекта. Материал можно рассматри-
вать, как связь между индивидуальным объектом, который частично
состоит из другого объекта, и этим объектом, который, в свою очередь,
более или менее равномерно распределен в первом объекте. Например,
ложка сахара, растворенная в стакане чая, становится материалом для
этого напитка.
Части (Parts) рассматриваются как связи индивидами и их состав-
ляющими. Составляющие здесь понимаются в широком контексте. Это
могут быть, например, пространственные составляющие, временные со-
ставляющие, понятийные составляющие, члены группы и т.п. Части
используются, чтобы сказать, что некоторый объект является, в неко-
тором смысле, частью целого. В онтологии Cyc наиболее часто исполь-
зуются такие части, как физические составляющие, подсобытия, вре-
234
менные отрезки и члены групп.
Класс Статическая Ситуация (Static Situation) является подклас-
сом класса Временная Ситуация (Temporal Situation). Каждая стати-
ческая ситуация представляет собой состояние некоторой связи между
двумя и более объектами, статично существующими на некотором вре-
менном промежутке. Статические ситуации всегда имеют временную
протяженность и часто имеют пространственную протяженность и ма-
териальное воплощение. Например, рассмотрим ситуацию: «Президент
Дмитрий Анатольевич Медведев сидит на стуле 22 августа 2009 года».
Здесь есть два объекта: «Дмитрий Анатольевич Медведев» и «стул», а
также множество связей между этими объектами: «спинка стула под-
держивает спину Президента», «сидение стула реагирует на вес Прези-
дента» и т.д.
Изменения Физических Состояний (Physical State Changes) и
Трансформирующие События (Metamorphosis Events) и другие события
подобного рода можно рассматривать, как изменения, выражающиеся
в том, что нечто перестает существовать и другое нечто начинает.
Класс Физический Агент (Physical Agent) представляет объекты,
которые существуют и, по меньшей мере, имеют материальное вопло-
щение. Каждый Физический Агент имеет желания и намерения, а так-
же возможности эти желания и намерения осуществить. Агенты могут
быть индивидуальными или состоять из нескольких агентов, действу-
ющих вместе.
План (plan)— это последовательность шагов, которая, будучи испол-
нена в должном временном порядке, приведет к достижению некоторой
цели или к осуществлению некоторой задачи.
Цели (goals). В системе Cyc цели представляют собой характеристи-
ки отношений между агентами и формулами, описывающими состояния
вещей, для достижения которых эти агенты намереваются предпринять
определенные шаги. Также, цель можно рассматривать как атрибут от-
ношения между агентом и статической ситуацией, описываемой неко-
торой Cyc формулой.
Актеры (Actors) представляют собой вид отношения между собы-
тием и любым существующим объектом, который каким-либо образом
вовлечен в это событие. Иначе говоря, когда говорят, что кто-то или
что-то является действующим лицом (актером) данного события, под-
разумевается, что этот кто-то или что-то как-то вовлекается в данное
событие в течении его протекания. При этом, следует заметить, что
актер не всегда играет активную роль в событии. Примером может
служить «чеховское ружье», которое, если уж висит на стене на протя-
жении действия, то обязательно должно выстрелить в конце спектакля.
235
Действия (actions) представляют собой события, которые осуществ-
ляются некоторым действующим лицом. Действия— это события, в ко-
торых один или более актеров производят некоторые изменения в со-
стоянии мира, обычно выражающиеся в некоторой трате усилий. При
этом, необязательно, чтобы в результате произошли какие-то матери-
альные изменения (перемещение объектов или их разрушение). Напри-
мер, действие может заключаться в изменении счета клиента в банке.
Также, актер не обязательно должен быть одушевленным объектом.
Например, авария газопровода на Озерной улице в Москве в 2009 году,
когда огнем горящего газа было повреждено множество автомобилей
(здесь актером является газовый факел).
Класс Агент (Agent) представляет объекты, которые имеют же-
лания и намерения, а также возможности эти желания и намерения
осуществить. Агенты могут быть индивидуальными или состоять из
нескольких агентов, действующих вместе.
Фиолетовый уровень
На этом уровне находятся знания, которые у человека обычно рассмат-
риваются как его знания об окружающем мире, т.е. о различных его ас-
пектах. Среди таких знаний есть знания о солнечной системе, ее устрой-
стве, количестве планет и т.д. Есть знания о дальнем космосе, т.е. о
звездах галактиках и других подобных объектах, эти знания объедине-
ны в раздел «астрономия». Человек имеет понятие об окружающих его
предметах, поэтому и в Cyc есть специальный класс Физический Ар-
тефакт (Physical Artifact), которому принадлежит великое множество
объектов нашего мира. Знания о структуре веществ объединены в раз-
дел «Химия». В этом разделе есть подразделы вида «Аналитическая
Химимя», «Вычислительная Химия», «Электрохимия» и т.д. Знания
о континентах, морях и океанах объединены в раздел под названием
«Естественная География», а знания о геополитическом устройстве ми-
ра— в раздел «Политичесая География». Элементы политической кар-
ты мира— это нации, правительства и геополитические объекты (груп-
пы лиц, контролирующих тот или иной регион). Имеются также знания
о различного рода организациях, их типах, а также о коммерческих и
военных организациях. Система Cyc также знает о живых организмах
в общем (так называемые Living Things), а также о конкретных расте-
ниях и животных. Имеются знания об экологии, социальном поведении
и законе.
236
Синий, умеренно-синий и темно-синий уровни
На синем уровне также как и на фиолетовом уровне, находятся знания
о различных сторонах окружающего мира, но уже более конкретные.
Например, один из разделов посвящен описанию автомобилей, зданий
и оружия, т.е. содержит описание знаний о конкретной стороне челове-
ческой жизни. Другой подобный раздел— это знания о промышленных
продуктах и о различных механизмах. На этом уровне также находят-
ся знания о языках, литературе и других областях искусства. На синем
уровне также находятся знания, связанные с различными областями
общественной деятельности. Это знания о структуре общества, а так-
же конкретные знания об элементах этой структуры. Например, име-
ются знания о спорте, продаже и торговле, путешествиях, профессиях,
политике и войнах и т.п.
На умеренно-синем уровне находятся знания о специфических об-
ластях человеческой деятельности. К таким знаниям можно отнести
здравоохранение, компьютерную безопасность, знания о некоторых ти-
пах химических реакций и т.п.
На темно-синем уровне находятся конкретные факты и знания. Это,
обычно, те знания, которые записываются в таблицах баз данных. Но,
в отличие от баз данных, конкретные знания в Cyc соединены с по-
нятиями верхнего уровня. Например, в системе Cyc имеются знания
о нескольких сотнях известных музыкантов. Система Cyc знает при-
мерно 85 вещей из тех, которые знают музыканты. Поэтому, например,
«Владимир Спиваков» это не просто запись в таблице, Cyc знает, что
Спиваков играет на скрипке, руководить ансамблем «Виртуозы Моск-
вы» и т.д. Вообще, в системе Cyc имеется возможность присоединять
существующие базы данных к системе. Идентифицируя столбцы таб-
лицы с понятиями онтологии Cyc, можно встроить базу данных в базу
знаний системы Cyc. Тогда, записи таблиц будут интерпретироваться
системой Cyc как суждения и будет иметься возможность задавать к
базе данных вопросы, делать выводы на основе фактов, расположенных
в этих базах данных и т.п.
237
5.5 Проект OpenCyc
Как уже говорились выше, проект OpenCyc представляет собой откры-

тую версию системы Cyc. OpenCyc состоит из следующих трех элемен-
тов:
∙ Машина логического вывода (inference engine).
∙ Браузер базы знаний OpenCyc.
∙ Набор интерфейсных функций (API) для написания программ,

которые могут взаимодействовать с онтологией OpenCyc.
Выше мы подробно обсуждали, как работает машина логического

вывода Cyc, а описание интерфейсных функций интересно, главным
образом, программистам. Поэтому здесь основное внимание уделим рас-
смотрению браузера базы знаний OpenCyc.
Сайт проекта OpenCyc (см. [5]) интересен еще и тем, что на нем
имеется достаточно подробная документация. Среди опубликованных
документов можно найти цикл пошаговых руководств (tutorials), посвя-
щенных различным аспектам работы с базой знаний OpenCyc. Также,
подробно описаны стили написания онтологий на языке CycL и различ-
ные аспекты, связанные с созданием онтологий. Например, тщательно
описываются события и связанные с ними понятия. Автор настоятель-
но рекомендует заинтересованному читателю просмотреть содержание
сайта проекта, наверняка будет найдено что-то интересное.
На момент написания текста книги разработчики OpenCyc собира-
лись выпустить вторую версию системы, но работа над ней еще не бы-
ла закончена. В связи с этим, здесь приведено описание первой версии
системы— так называемой Cyc-101. Строго говоря, здесь представлена
только общая информация об интерфейсе системы. Автор посчитал из-
лишним приводить подробное описание, т.к. на сайте проекта вся рабо-
та с системой хорошо документирована. Ниже просто дается небольшой
обзор, имеющий целью продемонстрировать возможности системы, не
более того.
Браузер базы знаний

Браузер онтологии OpenCyc представляет собой Web-сервер, который
устанавливается локально на компьютере пользователя и предоставля-
ет возможность обращаться к онтологии OpenCyc через интерфейсы,
238
предоставляемые этим сервером. Подробные инструкции по установ-
ке сервера даны на сайте проекта, поэтому здесь мы подобным вещам
уделять внимания не будем.
После установки, пользователь может перейти на начальную стра-
ницу Web-сервера, которая выглядит, как изображено на рисунке 5.3
Рис. 5.3: Начальная страница работы с Web-сервером OpenCyc.

Как видно из рисунка, страница браузера базы знаний разделена на
четыре панели:
1. Панель инструментов (Tools Frame или ToolBar Frame) предо-

ставляет пользователю следующую функциональность:
a) Искать в базе знаний константы, вводя их в Поисковое Поле

(Completion Box). Для поиска можно использовать три кноп-
ки: «Complete», «Show» и «Grep». Термин Complete означа-
ет Дополнение, т.е. если пользователь вводит в поле начало
имени константы, то в результате поиска показываются все
239
имена, имеющие в качестве начала введенную строку. Кноп-
ка «Show» (Показ) используется для показа констант, имена
которых полностью совпадают с введенным в поле именем
(обычно, такие имена вводятся на английском языке и по-
иск ведется в комментариях к константам. Например, поль-
зователь может ввести строку «William Jefferson Clinton»,
а в результате в панели индекса будет показана константа
$#BillClinton). И, наконец, кнопка «Grep» позволяет ис-
пользовать в поиске регулярные выражения, как это дела-
ется в известной поисковой утилите grep операционной си-
стемы UNIX. Кроме того, кнопку «Clear» (Очистить) можно
использовать для очистки поля ввода.
b) Перейти на страницы браузера, предоставляющие дополни-
тельную функциональность, используя для этого гиперссыл-
ки «Tools» (Инструменты) и «Navigation» (Переход).
c) Войти в систему под другим именем пользователя. Это мож-
но сделать через гиперссылку «Login» (Вход).
2. Панель Индекса (Index Frame) используется для показа информа-

ции о выбранных в онтологии Cyc константах. Панель содержит
список операций, которые могут быть осуществлены на показан-
ных в панели константах, а также список типов суждений, содер-
жащих эти константы. Содержание списка операций зависит от
содержания панели индекса, т.е. от тех констант, которые в этой
панели в данный момент показаны. Например, здесь также мо-
гут быть показаны ссылки на эвристические модули логического
вывода, используемые с константами, показанными в панели.
3. Панель Суждений (Assertion Display Frame) используется для по-

каза суждений, связанных с выбранными в панель индекса кон-
стантами. Очевидно, что содержание панели суждений зависит
от содержимого панели индекса. Для каждого суждения показы-
вается микротеория, которой это суждение принадлежит. Поль-
зователь может перейти по гиперссылке суждения к операциями
редактирования этого суждения. Операции редактирования поз-
воляют изменять суждение, удалить его или добавить в базу зна-
ний похожее суждение. Каждое суждение помечено шаром опре-
деленного цвета. Цвет шара представляет истинностное значение
данного суждения. Истинностные значения суждений мы уже об-
суждали выше. Белый шар означает, что суждение постоянно ис-
тинно, а желтый шар,— что суждение истинно по умолчанию.
240
4. Панель Системной Информации (Systems Information Frame)
предоставляет пользователю информацию о текущем состоянии
системы Cyc. Эту информацию можно обновить нажав на гиперс-
сылке «Update» (Обновить). Системная информацию включает,
гдавным образом, информацию о тех операциях, которые в дан-
ный момент осуществляются в системе.
Ниже будет рассмотрены некоторые наиболее интересные инстру-

менты, предоставляемые браузером базы знаний OpenCyc.
Операция ASK
Браузер базы знаний позволяет задавать системе Cyc вопросы, т.е. за-
пускать операции логического вывода. Для этого, необходимо кликнуть
на гиперссылке «Ask» в панели инструментов. В результате будет вы-
ведена страница запроса к онтологии OpenCyc, вид которой показан на
рисунке 5.4.
Рис. 5.4: Страница построения запроса к онтологии OpenCyc.

Пользователь может выбрать микротеорию, к которой будет про-
изводиться запрос, для чего можно использовать также и кнопку
«Completion» (дополнение). Также, константы в запросе можно вво-
дить без начальных «$#», но, в этом случае, необходимо будет нажать
241
кнопку «Cyclify» (сделать совместимыми с языком CycL) и имена будут
дополнены префиксом «$#». Сам запрос может быть выполнен нажа-
тием на кнопку «Ask query» (Выполнить запрос).
Добавление суждений на основе шаблонов

Другой интересный инструмент— это возможность добавлять в онтоло-
гию OpenCyc новые суждения, используя в качестве шаблона некоторое
уже имеющееся в базе знаний OpenCyc суждение. Шаги, которые долж-
ны быть последовательно осуществлены для добавления суждения на
основе шаблона, проиллюстрированы на рисунке 5.5. Для добавления
Рис. 5.5: Шаги для добавления суждения на основе шаблона.

суждения на основе уже имеющегося в базе знаний, необходимо сначала
кликнуть по шару суждения, в этом случае будет произведен переход на
страницу суждения. После этого, необходимо кликнуть на гиперссылке
«Assert Similar» (добавить подобное), в результате будет произведен пе-
реход на страницу добавления нового суждения на основе выбранного.
Обычно, новая формула просто добавляется без изменений в другую
микротеорию. Также, можно изменить содержание формулы перед до-
бавлением.
242
1. Алексеева М. А. Обзор системы Cyc. М.:РГГУ (2008). http://ezop-

project.wiki.sourceforge.net/Alekseeva_Cyc.
2. Клини С. Математическая логика. М.: Мир, 1973.
3. Лондон Дж. Морской волк. М.: АСТ, 2006.
4. Сайт компании Cycorp. http://www.cyc.com.
5. Сайт проекта OpenCyc. http://opencyc.org.
6. Страница описания контекстов Cyc.

http://www.cyc.com/cycdoc/course/contexts-basic-module.html.
7. Страница проекта Cyc в английской Википедии.

http://en.wikipedia.org/wiki/Cyc.
8. Страница описания онтологии Cyc.

http://www.cyc.com/cyc/technology/whatiscyc_dir/whatdoescycknow.
9. Страница описания языка CycL на сайте проекта Cyc.

http://www.cyc.com/cycdoc/ref/cycl-syntax.html.
10. Страница Cyc-NL. http://www.cyc.com/cyc/technology/

whatiscyc_dir/cycrandd/areasofrandd_dir/nlu.
11. Чень Ч, Ли Р. Математическая логика и автоматическое доказа-

тельство теорем. М.: Наука, 1983.
12. Хювёнен Э., Септянен И. Мир Лиспа. Том 1. Введение в язык Лисп
и функциональное программирование. М.: Мир, 1990.
13. Davidson C. Common Sense and the Computer. New Scientist. April
2, 1994.
14. Guha R., Lenat D., Pittman K., Pratt D., Shepherd M. Cyc: a midterm
report. Communications of the ACM, August 1990/ Vol 33. No 8.
15. Lenat D., Guha R. Building Large Knowledge Based Systems. Addison
Wesley, Reading Mass, 1990.
16. Lenat D., Guha R. Enabling Agents to Work Together,

Communications of the ACM, July 1994/ Vol 37. No. 7.
243
17. Lenat D. Steps to Sharing Knowledge. In Toward Very Large
Knowledge Bases. Edited by N.J.I. Mars. IOS Press, 1995.
18. Lenat D. Artificial Intelligence. Scientific American, September 1995.
244
Послесловие
В этой книге были рассмотрены различные аспекты применения онто-

логий для решения инженерных задач. За исключением первой главы,
которая главным образом была необходима для того, чтобы ввести чи-
тателя в круг задач, возникающих в машинной обработке знаний, про-
иллюстрировать роль онтологий в этих задачах и необходимость спе-
циального изучения последних, оставшаяся часть книги, фактически,
представляет собой обзор наиболее известных на момент ее написания
проектов по построению библиотек онтологий. Как читатель имел воз-
можность неоднократно убедиться в процессе чтения текста, построе-
ние хорошего проекта по обработке знаний немыслимо без предостав-
ления библиотеки онтологии этих знаний. В этом смысле, обработка
знаний и построение библиотек онтологий неотделимы.
Задача построения библиотек онтологий возникает также и в за-
дачах другого рода, где обработка знаний не является непосредствен-
ной целью создания информационной системы. Например, при созда-
нии Web портала, кроме собственно, основной задачи предоставления
информационных услуг пользователям, необходимо решить задачу по-
строения описания содержимого данной информационной системы по-
исковым Интернет-программам. Это описание должно быть в доста-
точной степени формальным, чтобы быть понятным поисковому робо-
ту, т.е. представлять собой ни что иное, как онтологию. Это, конечно,
не единственный пример того, когда задача построения описания со-
держимого информационной системы возникает не только в связи со
специфической задачей построения сервиса машинной обработки зна-
245
ний, но и как необходимый компонент построения любой информаци-
онной системы, функциональное предназначение которой не связано
непосредственным образом с задачей обработки знаний .
Почти во всех рассмотренных в книге информационных системах
построение онтологий базировалось на одной теоретической базе, а
именно: исчислении предикатов . В основном, онтологии представля-
ли собой множества высказываний, задаваемых предикатными выра-
жениями, на которые налагались те или иные ограничения в виде спе-
цифических аксиом. Предикатные выражения задавали факты об опи-
сываемом мире, т.е. язык исчисления предикатов, используемый для
описания знаний, являлся языком первого порядка. Резюмируя, можно
сказать, что традиционный и наиболее часто используемый в настоя-
щее время подход базируется на представлении онтологии посредством
языка исчисления предикатов первого порядка, в который часто до-
бавляются некоторые элементы второго порядка. Так, в языке OWL
можно указать некоторые характеристики свойств (предикатов), такие
как транзитивность или функциональность. Использование возможно-
стей языков второго и высшего порядков строго ограничено, что вы-
звано необходимостью обеспечить достаточно четкое описание знаний
и достаточно быстрые процедуры логического вывода на основе этих
знаний.
Исчисление предикатов представляет собой хорошо изученную об-
ласть, поэтому вполне естественно, что большинство реализаций проек-
тов построения библиотек онтологий использует этот формализм. Но,
кроме исчисления предикатов, имеются и другие подходы к описанию
знаний. Так, в последнее время приобрел популярность алгебраический
подход к описанию знаний. На основе этого подхода создаются систе-
мы построения библиотек онтологий, которые не были здесь описаны
ввиду недостатка места, а также, главным образом, ввиду их недоста-
точной апробированности. В алгебраическом подходе знания представ-
ляются в виде множеств выражений специального вида— термов . На
вид термов налагаются ограничения посредством аксиом эквивалент-
ности. На множествах термов можно производить вычисления , отвечая
тем самым на различные вопросы к онтологии и порождая в процессе
вычислений новые знания. Описание алгебраического подхода к пред-
ставлению знаний требует, наверное, отдельной главы.
Знания представляют собой социальный феномен. Знания возни-
кают как результат договоренностей между людьми, т.е. формируют-
ся коллективно. Эта особенность коллективного формирования знаний
должна быть отражена в инструментах, предоставляемых пользовате-
лям системой построения библиотек онтологий. Конечно, существую-
246
щие системы, в особенности те, для создания которых привлекались
достаточно большие коллективы разработчиков, должны были реали-
зовать подобные инструменты. Но, специальным образом процесс кол-
лективного формирования онтологий не изучался. Для описания ме-
тодов и подходов, которые необходимо использовать для построения
систем, предоставляющих инструменты для коллективного формиро-
вания онтологий, необходима отдельная глава.
Системы построения библиотек онтологий обычно представляют
для описания знаний формальные языки, которые достаточно слож-
ны для изучения и реализации. Для того, чтобы иметь возможность
полноценно описывать знания в библиотеке онтологий, пользователь
должен изучить язык, на котором эти знания задаются в системе, а
также принципы, на основе которых эти знания формируются в дан-
ной системе. Это довольно трудоемкий процесс. Большое количество
затруднений вызвано тем, что язык, на котором описываются знания,
в недостаточной мере синтаксически гибок для удобного выражения
онтологических фактов. В повседневной жизни для выражения новых
фактов люди изменяют синтаксис и лексику языка, с тем чтобы удобно
описывать новые знания. В этом смысле, язык повседневного общения
открыт . Реализация открытого языка описания знаний является до-
статочно трудоемкой задачей, решение которой требует специального
изучения и применения специфических методов, как синтаксического
анализа, так и специальных подходов к моделированию таких попол-
няющихся знаний. Очевидно, что для полноценного описания возника-
ющих проблем требуется специальная глава.
Таким образом, еще остается множество вопросов, на которые в дан-
ной книге не было дано ответа. Можно сказать, что данная книга по-
крывает проблематику, отражающую современное состояние дел в об-
ласти построения библиотек онтологий. Вопросы, касающиеся развития
существующих идей в данной области здесь не обсуждались. Автор на-
деется, что труд, посвященный описанию этих проблем, вскоре будет
написан.
247

Онтологии в Информационных Системах

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Онтологии в Информационных Системах

Загружено:

Авторское право:

Доступные форматы

В.А.

2 Различные аспекты применения онтологий 37

3 OWL— язык описания онтологий для Web 90

4 Ontolingua— Web-сервер библиотек онтологий 142

5 Cyc— библиотеки онтологий для AI 195

Развитие информационных технологий последней четверти прошлого

Москва, сентябрь 2009 года.

1.1 О чем эта книга

Эта книга представляет собой попытку систематически изложить раз-

В полном соответствии с традициями инженерной науки, возникла

Рис. 1.1: Обмен знаниями между экспертными системами.

Рис. 1.2: Описания Web-страниц для поисковых программ.

Рис. 1.3: Онтология как интерфейс к базе знаний.

1. Общие или абстрактные знания, описанные в онтологии верхнего

2. Знания о конкретной предметной области (domain specific

3. Конкретные знания, добавляемые в базу знаний пользователями

Разделение знаний на уровни вообще свойственно человеку, об этом мы

Термин «онтология» не нов и используется в философии уже около

Определение 1.1 Онтология (в философии)— это раздел философии,

Знание— это нечто, что может быть объяснено (программ-

∙ Выделить в системе управления знаниями уровень так называемо-

∙ База знаний предоставляет описание своего декларативного зна-

Рис. 1.4: Различные концептуализации объекта «дом».

Это расхождение в целях концептуализации явилось мотивацией для

Определение 1.2 Концептуальной схемой инженерной задачи назы-

1.3 Типы онтологий

В данном разделе мы рассмотрим различные типы онтологий, начи-

биваются на типы5 и между введенными типами вводится отношение

Подобные классификации существуют во всех популярных поисковых

1. Как прямоугольник, у которого стороны равны друг другу.

2. Как ромб с равными углами.

∙ Слова. Иначе говоря, слова являются объектами любой предмет-

∙ Все комплексные числа.

∙ Все множества объектов предметной области.

∙ Специальный объект, обозначаемый ⊥, который считается значе-

Функция— это вид соотношения между объектами. С каждой ко-

1. Рефлексивность. Для любого объекта 𝑎 выполняется 𝑎 6 𝑎.

3. Транзитивность. Если 𝑎 6 𝑏 и 𝑏 6 𝑐, то выполняется 𝑎 6 𝑐.

Итак, частичный порядок— это любое двуместное отношение, для ко-

1. «?r» представляет собой бинарное отношение (binrel ?r, ?s), т.е.

2. Для каждого объекта «?x» (forall ?x) множества «?s»

Наверное, единственное что здесь требует комментария, это отноше-

1.4 Что изложено в книге

Книга посвящена изложению современных систем построения онтоло-

∙ Методология, предложенная разработчиками языка UML [24], со-

∙ Методология, предложенная Грубером в статье «Предполагаемые

∙ Методология, основанная на так называемом BORO-методе раз-

Глава 3 посвящена изложению языка OWL [10] и связанных с этим

1. Бобров Е. Г. Карл Линней. 1707—1778. — Л.: Наука. 1970. — 285 с.

2. Гоклениус Р. Lexicon philosophicum, quo tanquam clave philisophiae

3. Драфт стандарта dpANS языка KIF.

4. . Клауберг И. Metaphysika de ente, quae rectus Ontosophia. Амстер-

5. Когаловский М., Калиниченко Л. Концептуальное моделирование

6. Линней К. Система природы. Царство животных, ч. 1–2. СПб,

7. Маклейн С. Категории для работающего математика. Перевод под

8. Менделеев Д. И., Периодический закон. Основные статьи, М., 1958.

9. Описание концепций языка RDF на сайте W3.

10. Описание языка OWL на сайте W3. http://www.w3.org/TR/owl-

11. Описание языка XML на сайте W3. http://www.w3.org/XML/.

12. Сайт Каталога Яндекса. http://catalog.yandex.ru/.

13. Сайт компании Cycorp. http://www.cyc.com.

14. Сайт Онтолингва. http://www.ksl.stanford.edu/software/ontolingua/.

15. Сайт, посвященный BORO методологии.

16. Сайт проекта OpenCyc. http://opencyc.org.