Страница 117

Рис. 8.6. Взаимосвязь между онтологиями онтологической системы

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

• с активацией понятий и/или отношений, фиксирующих решаемую задачу (описание исходной ситуации);

• определением целевого состояния (ситуации);

• выводом на сети, заключающемся в том, что от узлов исходной ситуации распространяются волны активации, использующие свойства отношений, с ними связанных. Критерием остановки процесса является достижение целевой ситуации или превышение длительности исполнения (time-out).

8.2.3. Методологии создания

и «жизненный цикл» онтологии

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

Следует сразу отметить, что эти подходы и методологии базируются на следующих принципах проектирования и реализации онтологии, предложенных. Грубером [Gmber, 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). И только после этого — остальные промежуточные представления.