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 Environment) [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. Фрагмент глоссария

Когда глоссарий терминов достигает «существенного» объема, строятся деревья классификации концептов. Как правило, при этом используются отношения типа 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.7. фрагмент описания аксиомы The-Head-Of-Project-Works-ln-The-Project

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

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

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

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

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

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