Модели онтологии и онтологической системы

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

Под формальной моделью онтологии О будем понимать упорядоченную тройку вида:

где

X - конечное множество концептов (понятий, терминов) предметной области, кото­рую представляет онтология О;

- конечное множество отношений между концептами (понятиями, терминами) заданной предметной области;

Ф - конечное множество функций интерпретации (аксиоматизация), заданных на концептах и/или отношениях онтологии О.

Заметим, что естественным ограничением, накладываемым на множество X, яв­ляется его конечность и непустота. Иначе обстоит дело с компонентами Ф и в определении онтологии О. Понятно, что и в этом случае Ф и должны быть ко­нечными множествами. Рассмотрим, однако, граничные случаи, связанные с их пустотой.

Пусть = Ø и Ф = Ø. Тогда онтология О трансформируется в простой словарь:

О =V = <X, {},{}>.

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

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

Другой вариант соответствует случаю = Ø, но Ф ≠ Ø. Тогда каждому элементу множества терминов из X может быть поставлена в соответствие функция интер­претации f из Ф. Формально это утверждение может быть записано следующим образом.

Пусть

X = X₁ X₂,

причем

Х₁ Х₂ = Ø,

где X₁ - множество интерпретируемых терминов;

Х₂ - множество интерпретирующих терминов.

Тогда

такие что

где

Пустота пересечения множеств X ₁ и Х₂ исключает циклические интерпретации, а введение в рассмотрение функции k аргументов призвано обеспечить более пол­ную интерпретацию. Вид отображения f из Ф определяет выразительную мощ­ность и практическую полезность этого вида онтологии. Так, если предположить, что функция интерпретации задается оператором присваивания значений (X₁:= Х₂, где X₁ - имя интерпретации Х₂), то онтология трансформируется в пассивный словарь V^p:

О = V^P = <X₁ X₂, {},{:=}>

Такой словарь пассивен, так как все определения терминов из X₁ берутся из уже существующего и фиксированного множества Х₂. Практическая ценность его, выше, чем простого словаря, но явно недостаточна, например, для представления знаний в задачах обработки информации в Интернете в силу динамического ха­рактера этой среды.

Для того чтобы учесть последнее обстоятельство, предположим, что часть интер­претирующих терминов из множества Х₂ задается процедурно, а не декларативно. Смысл таких терминов «вычисляется» каждый раз при их интерпретации.

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

Для представления модели онтологии, которая нужна для решения задач обра­ботки информации в Интернете, очевидно, требуется отказаться от предположе­ния = Ø.

Итак, предположим, что множество отношений на концептах онтологии не пусто, и рассмотрим возможные варианты его формирования.

Для этого введем в рассмотрение специальный подкласс онтологии - простую таксономию следующим образом:

О = Т° = < X, {is_a}, {}>.

Под таксономической структурой будем понимать иерархическую систему понятий, связанных между собой отношением is_a («быть элементом класса»).

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

Результаты анализа частных случаев модели онтологии приведены в таблице 8.1.

Таблица 8.1. Классификация моделей онтологии

Компоненты модели	= Ø Ф = Ø	= Ø Ф Ø	= Ø Ф Ø	= {is_a} Ф = Ø
Формальное определение	<Х, {},{}>	<Х1 Х2,{},Ф>	<Х1<Х1 (Х2* р2*),{},Ф>	<X, is_a},{}>
Пояснение	Словарь ПО	Пассивный словарь ПО	Активный словарь ПО	Таксономия понятий ПО

Далее можно обобщить частные случаи модели онтологии таким образом, чтобы обеспечить возможность:

• представления множества концептов X в виде сетевой структуры;

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

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

Тогда можно ввести в рассмотрение модель расширяемой онтологии и исследовать ее свойства. Однако, учитывая техническую направленность данной книги, мы не будем делать этого здесь, а желающих познакомиться с такой моделью отсылаем к работе [Maikevich et al., 1999]. Как показано в этой работе, модель расширяемой онтологии является достаточно мощной для спецификации процессов формиро­вания пространств знаний в среде Интернет. Вместе с тем и эта модель является неполной в силу своей пассивности даже там, где определены соответствующие процедурные интерпретации и введены специальные функции пополнения онто­логии. Ведь единственной точкой управления активностью в такой модели явля­ется запрос на интерпретацию определенного концепта. Этот запрос выполняется всегда одинаково и инициирует запуск соответствующей процедуры. А собствен­но вывод ответа на запрос и/или поиск необходимой для этого информации оста­ется вне модели и должен реализовываться другими средствами.

Учитывая вышесказанное, а также необходимость эксплицитной спецификаций процессов функционирования онтологии, введем в рассмотрение понятие онто­логической системы

Под формальной моделью онтологической системы будем понимать триплет вида:

Где онтология верхнего уровня (метаонтология);

множество предметных онтологий и онтологий задач предметной области;

- модель машины вывода, ассоциированной с онтологической системой .

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

В модели имеются три онтологические компоненты:

• метаонтология;

• предметная онтология;

• онтология задач.

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

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

Отношение part_of определено на множестве концептов, является отношением принадлежности и показывает, что концепт может быть частью других концеп­тов. Оно является отношением типа «часть-целое» и по свойствам близко к от­ношению is_a и может быть задано соответствующими аксиомами. Аналогич­ным образом можно ввести и другие отношения типа «часть-целое».

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

X see_also Y:

see_also member_of Relation {

if ((X is_a Notion) & (Y is_a Notion) & (X see_also Y))

if (Operation connected_with X)

Operation connected_with Y

};

Заметим, что и отношение see_also «не вполне» транзитивно. Действительно, если предположить, что (XI see_also Х2) & (Х2 see_also X3), то можно считать, что (XI see_also ХЗ). Однако по мере увеличения длины цепочки объектов, связанных данным отношением, справедливость транзитивного переноса свойства connected_with падает. Поэтому в случае отношения see_also мы имеем дело не с отношением частичного порядка (как, например, в случае отношения is_a), а с отношением толерантности. Однако для простоты это ограничение может быть перенесено из определения отношения в функцию его интерпретации. Анализ различных предметных областей показывает, что введенный выше набор отношений является достаточным для начального описания соответствующих онтологии. Понятно, что этот базис является открытым и может пополняться в зависимости от предметной области и целей, стоящих перед прикладной систе­мой, в которой такая онтология используется.

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

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

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

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

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

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

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» «[email protected]»

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

При этом:

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

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

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

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

Дата добавления: 2015-07-02