8.2.3. Методологии создания и «жизненный цикл» онтологий

Как уже отмечалось выше, разработчики систем, основанных на знаниях, сталки­ваются с проблемой «узкого горлышка» приобретения знаний. Аналогичная про­блема существует и при создании онтологий. Но, в отличие от разработчиков интеллектуальных систем, создателей онтологий ждут и дополнительные про­блемы, связанные с отсутствием сколько-нибудь общих и верифицированных ме­тодологий, определяющих, какие «процедуры» должны выполняться в процессе разработки и на каких стадиях разработки онтологий они должны выполняться. В настоящее время существует лишь несколько предметно-независимых методо­логий, ориентированных на построение онтологий [Gruninger et al., 1995; Ushold, et al., 1996; Fernandez et al, 1997].

Следует сразу отметить, что эти подходы и методологии базируются на следую­щих принципах проектирования и реализации онтологий, предложенных Грубе­ром [Gruber, 1993]:

1. Ясность (Clarity) - онтология должна эффективно передавать смысл вве­денных терминов. Определения должны быть объективными, хотя моти­вация введения терминов может определяться ситуацией или требования­ми вычислительной эффективности. Для объективизации определений должен использоваться четко фиксированный формализм, при этом целе­сообразно задавать определения в виде логических аксиом.

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

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

4. Минимум влияния кодирования (Minimal encoding bias) - концептуализация, ле­жащая в основе создаваемой онтологии, должна быть специфицирована на уровне представления, а не символьного кодирования. Этот принцип связан с тем, что агенты, разделяющие онтологию, могут быть реализованы в различ­ных системах представления знаний.

5. Минимум онтологических обязательств (Minimal ontological commitment) - он­тология должна содержать только наиболее существенные предположения о моделируемом мире, чтобы оставлять свободу расширения и специализации. Отсюда следует, что онтологии базируются на «слабых» теориях, так как цель их создания и использования состоит, прежде всего, в том, чтобы «говорить» о предметной области, в отличие от БЗ, которые могут содержать знания, необ­ходимые для решения задач и/или ответов на вопросы.

Методологию и «жизненный цикл» создания онтологий обсудим на примере под­хода METHONTOLOGY, разработанного Гомез-Перезом (Gomez-Perez) с коллегами, в рамках которого реализуются принципы Грубера, а также разработано программное окружение спецификации онтологии ODE (Ontology Design Envi­ronment) [Blazquez et al., 1998].

В рамках этого подхода выделяются следующие процедуры в «жизненном цик­ле» создания онтологии: управление проектом, собственно разработка и поддерж­ка разработки.

Процедуры управления проектом включают планирование, контроль и гарантии качества. Планирование определяет, какие задачи должны быть выполнены, как они организуются, как много времени и какие ресурсы нужны для их выполнения. Контроль гарантирует, что запланированные задачи выполнены и именно так, как это предполагалось. Гарантии качества нужны для того, чтобы быть уверенным в том, что компоненты и продукт в целом находятся на заданном уровне. Собственно разработка включает спецификацию, концептуализацию, формали­зацию и реализацию. Спецификация определяет цели создания онтологии, ее предполагаемое использование и потенциальных пользователей. Концептуали­зация обеспечивает структурирование предметных знаний в виде значимой экс­плицитной модели. Формализация трансформирует концептуальную модель в формальную или «вычислительную». Наконец, в процессе реализации вычисли­тельная модель программируется на соответствующем языке представления зна­ний.

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

Общая схема «жизненного цикла» создания онтологий в рамках подхода МЕТHONTOLOGY представлена на рис. 8.7.

Заметим, что процесс построения онтологии здесь распадается на серию подпро­цессов по созданию промежуточных представлений. При этом выполнение от­дельных подпроцессов не последовательное (в смысле «водопадной» модели жиз­ненного цикла, обсуждавшейся в предыдущей главе), а определяется полнотой и точностью уже накопленных знаний. Однако, как показывает опыт, сначала стро­ится глоссарий терминов (Glossary of Terms), затем деревья классификации концептов (Concept Classification Trees) и диаграммы бинарных отношений (Binary Relations Diagrams). И только после этого - остальные промежуточные

Рис. 8.7. «Жизненный цикл» создания онтологий в рамках подхода METHONTOLOGY

Для иллюстрации результатов, получаемых на разных этапах создания онтоло­гии в рамках подхода METHONTOLOGY, будем предполагать, следуя работе [Blazquez et al., 1998], что предметной областью разработки является сообщество специалистов по приобретению знаний, работающих в контексте инициативы (КА)² [Benjamins et al., 1998].

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

Таблица 8.2. Фрагмент глоссария

Термин

Описание термина

Academic Staff Researcher Nicola Guarino Weight ……………..

«Он\она может быть лектором или исследователем. Одна из возможных обязанностей - руководство аспирантами» «Он\она является членом Academic Staff, может быть членом исследовательской группы и кооперироваться с другими исследователями» «Он является исследователем CNR National Research Council. Его исследования связаны с онтологиями. Он работает по проекту OntoSeek» «Вес человека. Измеряется в килограммах» «……………………………………………»

Когда глоссарий терминов достигает «существенного» объема, строятся деревья классификации концептов. Как правило, при этом используются отношения ти­па subclass-of и некоторые другие таксономические отношения. Таким образом, идентифицируются основные таксономии предметной области, а каждая таксо­номия, согласно рассматриваемой методологии, дает в конечном счете онтоло­гию. В рамках инициативы (КА)² идентифицировано несколько таксономий, ос­новные из которых people, publications, events, organizations и research topics. Фрагменты некоторых из них представлены на рис. 8.8.

Рис. 8.8. Фрагменты таксономий, выделяемых в рамках инициативы (КА)²

Следующим шагом является построение «Ad hoc» диаграмм бинарных отноше­ний, целью создания которых является фиксация отношений между концептами одной или разных онтологий. Заметим, что в дальнейшем эти диаграммы могут послужить исходным материалом для интеграции разных онтологий. Пример одной из таких диаграмм приведен на рис. 8.9.

Рис. 8.9. Фрагмент диаграммы бинарных отношений, выделяемых в рамках инициативы (КА)²

После построения представлений, фиксированных выше, для каждого дерева классификации концептов строятся:

1. Словарь концептов (Concept Dictionary), содержащий все концепты предмет­ной области, экземпляры таких концептов, атрибуты экземпляров концептов, отношения, источником которых является концепт, а также (опционально) си­нонимы и акронимы концепта. Фрагмент такого словаря представлен в табл. 8.3.

2. Таблица бинарных отношений (Table of Binary Relations) для каждого «Ad hoc» отношения, исходный концепт которого содержится в классификационном де­реве. Для каждого отношения фиксируется его имя, имена концепта-источни­ка и целевого концепта, инверсное отношение и т. п. характеристики. Пример двух таблиц этого типа представлен в табл. 8.4, 8.5.

3. Таблица атрибутов экземпляра (Instance Attribute Table) для каждого экземп­ляра из словаря концептов. Основные характеристики здесь следующие: имя атрибута, тип значения, единица измерения, точность, диапазон изменения, значение «по умолчанию», атрибуты, которые могут быть выведены с исполь­зованием данного, формула или правило для вывода атрибута и др. Пример описания атрибутов экземпляра Weight показан в табл. 8.6.

4. Таблица атрибутов класса (Class Attribute Table) для каждого класса из слова­ря концептов с аналогичными характеристиками.

5. Таблица логических аксиом (Logical Axioms Table), в которой даются опреде­ления концептов через всегда истинные логические выражения. Определение каждой аксиомы включает ее имя, естественно-языковое описание, концепт, к которому аксиома относится, атрибуты, используемые в аксиоме, логическое выражение, формально описывающее аксиому, и др. Пример описания аксио­мы приведен в табл. 8.7.

6. Таблица констант (Constants Table), где для каждой константы указывается ее имя, естественно-языковое описание, тип значения, само значение, единица из­мерения, атрибуты, которые могут быть выведены с использованием данной константы, и т. п.

7. Таблица формулы (Formula Table) для каждой формулы, включенной в таб­лицу атрибутов экземпляра. Каждая таблица этого типа, помимо собственно формулы, должна специфицировать ее имя, атрибут, выводимый с помощью этой формулы, естественно-языковое описание, точность, ограничения, при ко­торых возможно использовать формулу, и др.

8. Деревья классификации атрибутов (Attribute Classification Trees), которые гра­фически показывают соответствующие атрибуты и константы, используемые для вывода значения корневого атрибута и формулы, применяемые для этого. По сути дела, эти деревья используются для проверки того, что все атрибуты, представленные в формуле, имеют описания и ни один из атрибутов не пропу­щен.

9. Таблица экземпляров (Instance Table) для каждого входа в словарь концептов. Здесь специфицируется имя экземпляра, его атрибуты и их значения. Пример фрагмента таблицы экземпляров представлен в табл. 8.8.

Таблица 8.3. Фрагмент словаря концептов

Имя концепта …	Экземпляр	Атрибуты экземпляра	Отношение
Academic-Staff Person Researcher …	- Gomez-Perez …	Age First-Name Last-Name Photo Weight ……….. - …	Supervises Has-Publications Editor-of ………. Cooperates-with Research-Interest Member-of-Research-Group …

Таблица 8.4. Фрагмент описания отношения Employs

Имя отношения	Employs
Исходный концепт	Organization
Кардинальность	(1, n)
Целостный концепт	Employee
Математические свойства	-
Инверсные отношения	Affiliation
Ссылки	-

Таблица 8.5. Фрагмент описания отношения Affiliation

Имя отношения	Employs
Исходный концепт	Organization
Кардинальность	(1, n)
Целостный концепт	Employee
Математические свойства	-
Инверсные отношения	Affiliation
Ссылки	-

Таблица 8.6. Фрагмент описания атрибутов экземпляра Weight

Имя атрибута экземпляра	Weight
Тип значения	Mass-Quantity
Единица измерения	Kilogram
Точность	0.001
Диапазон	[0,200]
Значение «по умолчанию»	-
Кардинальность	(1,1)
Выводится из атрибута экземпляра	-
Выводится из атрибута класса	-
Выводится из констант	-
Формула ………………………	- …………….

Таблица 8.7. Фрагмент описания аксиомы The-Head-Of-Project-Works-ln-The-Project

Имя аксиомы	The-Head-Of-Project-Works-ln-The-Project
Описание	«Работник, являющийся руководителем проекта, работает в проекте»
Концепт	Employee
Ссылочные атрибуты	-
Переменные	Е, Р
Определение ……………	Forall (E, P) Employs (E) and Head-Of-Project (Е, Р) => Works-At-Project(E, P) ……………

Таблица 8.8. Фрагмент таблицы экземпляров

Экземпляр	Атрибут	Значение
Gomez-Perez	Full Name First Name Last Name E-Mail	«Asuncion Gomez-Perez» «Asuncion» «Gomez-Perez» «asun@fi.upm.es»

Как показывает анализ приведенных выше процедур, выполняемых при создании онтологий в подходе METHONTOLOGY, все они хорошо коррелируют с теми стадиями, которые выделены и используются при построении баз знаний. И это не случайное совпадение, а закономерность, связанная с тем, что онтология - это, по существу, БЗ специального вида. Поэтому, как и в случае построения баз зна­ний, здесь используется концепция быстрого прототипирования, а специфика проявляется в тех конкретных процессах, которые реализуют рассмотренные выше процедуры.

При этом:

• планирование выполняется до начала собственно разработки;

• контроль и гарантии качества осуществляются в процессе разработки;

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

• интеграция не должна рассматриваться как интеграция на стадии реализации. Напротив, она выполняется в процессе разработки.