Методы и методологии разработки, сопровождения и

Методы и методологии
разработки, сопровождения
и реинжиниринга онтологий
Загорулько Ю.А.
Институт систем информатики
имени А.П. Ершова СО РАН
1
План доклада
Введение
 Методологии и методы построения
онтологий «с нуля»
 Метод реинжиниринга онтологий
 Методы коллективной разработки
онтологий
 Методы и методологии слияния
онтологий

2
Характеристики для оценки
методологий и методов




Предложенная стратегия
конструирования
Предложенный процесс разработки
онтологий
Использование методологии
Технологическая поддержка
3
Характеристики для оценки
методологий и методов

Предложенная стратегия
конструирования


Предложения по жизненному циклу
Стратегия отношения к приложению
(методы – зависимые, независимые и полузависимые
от приложения)


Использование ядерных (базовых)
онтологий
Стратегия идентификации понятий
(стратегии bottom-up, top-down, middle-out)
4
Характеристики для оценки
методологий и методов

Предложенный процесс разработки
онтологий


Процессы управления проектом
Процессы, связанные с разработкой
онтологий
(выбор и установка среды, спецификация требований,
проектирование онтологии, реализация, установка,
использование, сопровождение, вывод из
эксплуатации)

Интегральные процессы (обеспечивают
завершение и качество всей деятельности в рамках
проекта)
5
Характеристики для оценки
методологий и методов

Использование методологии
(использование методологии в проекте,
принятие методологии другими группами,
онтологии, разработанные с помощью этого
подхода, их предметные области, системы,
где они используются)

Технологическая поддержка
(какие средства обеспечивают полную
или частичную поддержку методологии или
метода)
6
Методологии и методы
построения онтологий «с нуля»
(from scratch)


Метод Cyc
Метод Ушолда и Кинга (Uschold and King’s
method)

Методология Грюнингера и Фокса (Grüninger
and Fox’s methodology)




Метод KACTUS
Методология METHONTOLOGY
Метод SENSUS
Методология On-To-Knowledge
7
Метод Cyc
Методология Cyc интегрирует опыт разработки
базы знаний Cyc, содержащей большой объем
знаний «здравого смысла» (common sense knowledge)
Построение Cyc-онтологии включает фазы :



«Ручное» кодирование явных и неявных знаний,
содержащихся в источниках знаний
«Ручное» кодирование знаний с помощью
программных средств, используя знания, уже
сохраненные в БЗ Cyc
Полуавтоматическая фаза. Разработчик
рекомендует программным средствам для чтения
источники знаний и объясняет им наиболее сложные
8
места текста.
Метод Cyc
На каждой из фаз построения Cycонтологии выполняются две задачи :


Разработка представления знаний и онтологии
верхнего уровня, содержащей наиболее
абстрактные понятия. Термины, подобные таким,
как «атрибут» и «значение атрибута», являются
экземплярами терминов представления знаний, а
вещь (thing), неосязаемое (intangible) или коллекция
(collection) являются другими видами абстрактных
понятий.
Представление оставшихся знаний, используя
примитивы, созданные в первой задаче.
9
Использование метода Cyc



Cyc использовался в экспериментах в
высокопроизводительной базе знаний (HPKB) –
исследовательской программе, направленной на
продвижение технологии компьютерного
приобретения, представления и манипулирования
знаниями
Построение Cyc агентов, имеющих общее ядро в
виде знаний из БЗ Cyc и знания из своей
специфической области
До сих пор Cyc использовался только для
построения БЗ Cyc, однако Cyc имеет микро-теории,
включающие знания из разных ПО, представленных
с разных точек зрения. Эти микро-теории могут быть
использованы в определенных областях.
10
Приложения метода Cyc
Существует несколько модулей, интегрированных
в БЗ Cyc, и машина вывода.




Система интеграции гетерогенных баз данных.
Этот модуль отображает словарь Cyc в схемы баз данных.
В результате данные из БД интерпретируются в
соответствии с терминами словаря Cyc.
Модуль поиска по информации, содержащейся в подписях
к изображениям
Модуль интеграции структурированной терминологии
позволяет пользователям импортировать составные
тезаурусы (multiple thesauri) и одновременно управлять ими
и интегрировать их.
Модуль поиска информации в Интернет для расширения
БЗ Cyc.
11
Метод Ушолда и Кинга (Uschold and
King’s method)
Метод основан на разработке Enterprise Ontology,
т.е. онтологии для моделирования процессов на
предприятии.
Эта методология предлагает следующие этапы
разработки онтологий:




Определение цели
Разработка онтологии
Оценка
Документирование
12
Метод Ушолда и Кинга
Наиболее интересным этапом является
«Разработка онтологии» :

Фиксация онтологии





Выявление (идентификация) ключевых понятий и
отношений
(рекомендуется использовать middle-out подход: прежде
чем искать наиболее общие и наиболее частные понятия,
нужно определить наиболее важные понятия, которые
будут использоваться для достройки иерархий путем
обобщения и специализации)
Разработка точных текстовых определений для каждого
понятия и отношения
Выявление терминов, относящихся к каждому понятию и
отношению
Кодирование
Интеграция существующих онтологий
13
Приложения метода Ушолда и
Кинга


Наиболее важным проектом, разработанным в
рамках этой методологии является Enterprise
Ontology, которая является коллекцией терминов и
определений, относящихся к (торговопромышленным) предприятиям.
Эта онтология разработана в рамках Enterprise
Project при Artificial Intelligence Applications Institute в
the University of Edinburgh с такими партнерами как
IBM, Lloyd's Register, Logica UK Limited и Unilever.
Наиболее важным средством разработанным с
использованием Enterprise Ontology является
Enterprise Toolset. Оно использует основанную на
агентах архитектуру для интеграции стандартных
(серийно выпускаемых) программных средств в
стиле plug-and-play.
14
Методология Грюнингера и Фокса
(Grüninger and Fox’s methodology)
Методология основана на опыте разработки онтологии
TOVE, предназначенной для области моделирования
бизнес-процессов и бизнес-деятельности.
По существу, она включает построение логической
модели знаний, которая описывается с помощью
онтологии. Модель строиться не прямо, сначала
выполняется неформальное описание, состоящее из
спецификаций, которым должна удовлетворять
онтология.
15
Методология Грюнингера и Фокса
Предлагаются следующие этапы:



Фиксация мотивационного сценария
Формулирование неформальных вопросов проверки
компетенции
Спецификация терминологии онтологии на формальном
языке





Получение неформальной онтологии
Спецификация формальной терминологии
Формулирование вопросов компетенции с использованием
терминологии онтологии
Спецификация аксиом для терминов онтологии на
формальном языке.
Введение условий для описания полноты онтологии
16
Методология Грюнингера и Фокса
17
Использование методологии
Грюнингера и Фокса
Эта методология использовалась при создания
онтологий в проекте TOVE (Toronto Virtual Enterprise) в
лаборатории интеграции предприятий университета
Торонто.
Эти онтологии задают интегрированную модель,
формализованную с использованием логики первого
порядка.
TOVE онтологии включают: Онтологию Проектирования
Предприятия, Онтологию Проекта, Онтологию
Календарного Планирования и Онтологию Сервиса.
18
Приложения методологии
Грюнингера и Фокса
Онтологии, построенные в данной методологии,
используются в следующих приложениях:

Enterprise Design Workbench (АРМ для проектирования
предприятия).
Это среда проектирования, которая позволяет пользователю
исследовать множество проектов предприятия. Процесс
исследования – это либо проектирование, анализ или
перепроектирование. АРМ обеспечивает сравнительный анализ
альтернативных проектов предприятий и руководство
проектировщиком.

Integrated Supply Chain Management Project agents.
Его цель – организовать цепочки снабжения как сеть
взаимодействующих интеллектуальных агентов, каждый из
которых выполняет одно или несколько функций в цепочке
снабжения и координирует свои действия с другими агентами.
19
Метод KACTUS
Проект KACTUS выполнялся в рамках европейского
проекта Esprit.
Одной из целей проекта является исследование
возможности переиспользования знаний в сложной
технической системе и роль онтологии в поддержке
этого.
Этот подход зависит от приложения. Каждый раз, когда
создается приложение, строится и онтология,
представляющая требуемые для него знания.
Эта онтология может быть разработана путем
переиспользования других онтологий и интегрирована в
онтологии приложений, создаваемые позднее, поэтому
при разработке каждого приложения выполняются
следующие шаги:
20
Метод KACTUS
При разработке каждого приложения выполняются
следующие шаги:



Спецификация приложения
(обеспечивает контекст приложения и вид компонент, которые
приложение пытается моделировать)
Предварительный проект (эскиз) онтологии, основанный на
релевантных высокоуровневых онтологических категориях.
(поиск онтологий, разработанных для других приложений, их
уточнение и расширение для использования в новом
приложении)
Уточнение и структурирование онтологии, приведение к
окончательному варианту
(используются принципы минимальной связанности)
21
Использование метода KACTUS
В качестве опыта, основанного на этом подходе, авторы
представляют разработку трех онтологий как результат
разработки такого же числа приложений:



Цель первого приложения – диагностировать сбои в
электрической сети
Второе приложение связано с календарным планированием
восстановления работы электрической сети после сбоя
Третье приложение управляет электросетью на основе двух
предыдущих приложений.
22
Методология METHONTOLOGY
Методология разработана в лаборатории ИИ
Мадридского политехнического университета.
METHONTOLOGY обеспечивает конструирование
онтологий на уровне знаний.
Она базируется на основных видах деятельности,
выявленных из процесса разработки ПО (software) и
методологии инженерии знаний.
Она включает идентификацию процесса разработки
онтологий, жизненный цикл, основанный на эволюции
прототипов, и отдельные приемы для выполнения
каждой деятельности.
23
Процесс разработки и жизненный
цикл в METHONTOLOGY
24
Внешние и внутренние зависимости в
процессе разработки онтологии в
METHONTOLOGY
25
Использование методологии
METHONTOLOGY
Эта методология использовалась в UPM для построения
следующих онтологий:



CHEMICALS. Содержит знания в области химических
элементов и кристаллических структур.
Онтология Monatomic Ions. Собирает информацию об
одноатомных ионах.
Онтологии загрязняющих веществ окружающей среды.
Представляют методы обнаружения различных
загрязняющих компонентов разнообразных сред: воды,
воздуха, земли (грунта) и т.п., и максимальные
допустимые концентрации этих компонент с учетом
действующих законов
26
Использование методологии
METHONTOLOGY



The Reference-Ontology.
Это базовая онтология, описывающая предметные
области онтологий, которые являются видом
онтологий «желтых страниц» (справочников).
Реструктурированная версия онтологии (KA)2.
Содержит знания о научных сообществах в области
приобретения знаний, в частности, об ученых,
научных тематиках, проектах, университетах и т.п.
Онтология силикатов (Silicate ontology).
Моделирует свойства в области минералов, в
частности, силикатов.
27
Использование методологии
METHONTOLOGY



Онтологии управления знаниями ontologies (KM-LIA).
Обеспечивают необходимый словарь в области,
охватывающей людей, изученные уроки, машины, и
программы в лаборатории искусственного
интеллекта.
Онтологии, разработанные в проекте IST-1999-10589
MKBEEM о путешествиях, каталогах ткани и
сдаваемых квартирах (жилье), которая была
использована в мульти-язычной платформе для
электронной коммерции.
Онтология OntoRoadMap – об онтологиях,
методологиях разработки онтологий, средствах
разработки онтологий, событиях связанных с
онтологиями (конференции, семинары и т.п.) и др.
28
Приложения методологии
METHONTOLOGY
Приложения, которые используют некоторые из
перечисленных онтологий:

Onto)2Agent - является базированным на онтологии
WWW брокером онтологий, который использует
Reference-Ontology в качестве источника знаний и
находит описания онтологий, удовлетворяющих
заданному множеству ограничений.
29
Приложения методологии
METHONTOLOGY

Приложение OntoRoadMap application2, разработанное как
развитие (Onto)2Agent, является основанным на онтологии
web-приложением, которое позволяет сообществу
регистрировать, просматривать и находить онтологии,
методологии, программные средства и языки для
построения онтологий, онтолого-базированные
приложения в таких областях как semantic web, ecommerce, KM, NLP, III, и т.п., а также об основных
конференциях, семинарах, и событиях в этой области.
Оно был использовано в проекте IST-2000-29243 Ontoweb
thematic network

Ontogeneration [Aguado et al., 98] – это система, которая
использует (прикладную) онтологию CHEMICALS и
лингвистическую онтологию GUM, чтобы сгенерировать
описание текстов на испанском языке в ответ на запрос к
области химии.
30
Метод SENSUS
Онтология SENSUS предназначена для использования
в обработке текстов на ЕЯ. Разработана в группе
естественного языка института информационных наук
ISI (Information Sciences Institute) для поддержки
концептуальной структуры широкого назначения при
разработке машинных трансляторов.
Ее текущее содержание было получено путем
извлечения и слияния (вручную) информации из
различных электронных источников знаний:
(1) двух лингвистических онтологий высокого уровня
PENMAN Upper Model и ONTOS
(2) семантических категорий из словаря WordNet
(3) двух словарей – Collins Spanish/English dictionary и
Kenkyusha Japanese/English dictionary
31
Метод SENSUS
SENSUS имеет более 70 000 понятий, организованных
в иерархию в соответствии с их уровнями абстракции.
Он включает термины как высокого, так и среднего
уровня абстракции, но, вообще говоря, не покрывает
термины специфических областей.
Термины конкретных областей связываются с SENSUS
при построении для них онтологий, а любые
нерелевантные термины удаляются из SENSUS.
32
Метод SENSUS
При построении онтологии для прикладной области
выполняются следующие шаги:





Выбирается последовательность терминов в качестве
начальных (исходных).
Эти начальные термины вручную связываются с онтологией
SENSUS.
Все понятия на пути от начальных терминов до корня
SENSUS включаются в онтологию.
Термины, которые могли бы быть релевантными выбранной
области, но не встретившиеся на этом пути, добавляются в
онтологию.
Наконец, для тех вершин, через которые проходит много
путей, в ряде случаев добавляется полное поддерево.
33
Метод SENSUS
В результате применения этой последовательности
шагов получается скелетная онтология для данной
области.
Метод предлагает добавлять вручную новые термины в
этот скелет.
34
Использование метода SENSUS


С использованием SENSUS была разработана онтология
для планирования военных авиационных кампаний
(операций). Она включают набор базовых элементов,
характеризующих планы авиационных кампаний:
кампания, сценарий, участники, военачальники и др.
Эта онтология включает онтологии оружия, систем,
горючего и т.п.
На основе SENSUS в ISI совместно с ARPA Rome Planning
Institute program и позже с DARPA Joint Forces Air
Component Commander program. были разработаны
приложения для области планирования авиационных
компаний.
35
Методология On-To-Knowledge
Методология On-To-Knowledge была разработана и
применена в проекте EU IST-1999-10132 On-ToKnowledge для введения на предприятия и поддержки
приложений, осуществляющих основанное на
онтологии управление знаниями.
Она нацелена на Процессы Знаний и Метапроцессы
Знаний.
В то время как первые процессы нацелены на
использование онтологий, вторые управляют их
разработкой и начальной настройкой (установкой).
В связи с этим для нас особый интерес представляют
Метапроцессы.
36
Методология On-To-Knowledge
37
Сравнение стратегий конструирования
онтологий
38
Сравнение процессов разработки
онтологий
39
Использование предложенных
методологий разработки онтологий
40
Метод реинжиниринга онтологий
Реинжиниринг онтологии - это процесс получения
концептуальной модели уже реализованной онтологии
и отображения ее в другую, более подходящую
концептуальную модель, которая реализуется заново.
Рассмотрим метод реинжиниринга онтологий,
применяемый онтологической группой в UPM.
Этот метод адаптирует схему реинжиниринга
программного обеспечения Чиковского (Chikofsky) к
области онтологий.
41
Метод реинжиниринга онтологий
42
Метод реинжиниринга онтологий


Инженерный анализ (reverse engineering). Цель – получить
возможную концептуальную модель на основе кода онтологии.
Здесь используется множество промежуточных представлений,
предложенных METHONTOLOGY.
Реструктурирование (restructuring). Цель - преобразование
исходной концептуальной модели в новую концептуальную
модель с учетом использования реструктурированной онтологии
другими онтологиями или приложениями. Деятельность по
реструктуризации включает две фазы:



анализ (проверка того, что иерархия онтологии и ее классы,
экземпляры, отношения и функции полны, непротиворечивы (нет
конфликтов), не избыточны (нет явных или неявных повторений
(дублирования) и синтаксически корректны.
синтез (реализуется корректная онтология и документируются
любые сделанные изменения)
Прямая разработка (forward engineering). Цель - получить новую
реализацию онтологии на базе новой концептуальной модели.
43
Метод реинжиниринга онтологий
Некоторыми из онтологий, подвергшихся
реинжинирингу, являются онтология Standard Units и
онтологии, построенные в проекте IST-1999-10589
MKBEEM.
В первом случае потребовались единицы измерений
международной системы (International System), чтобы
построить Monatomic Ions. Это привело к
переиспользованию онтологии Standard Units, которая
входит в Ontolingua Server.
44
Методы коллективной
разработки онтологий

Co4: Совместная разработка
согласованных баз знаний

Метод Метод (KA)2
45
Co4: Совместная разработка
согласованных баз знаний
Co4 является инфраструктурой, обеспечивающей
совместное конструирование базы знаний через Web.
Разработка знаний мыслится как социальный процесс,
в который вовлечено сообщество множества агентов.
Система Co4 нацелена на поддержку разработки
знаний с помощью «знающих» людей, т.е. включение
процесса рецензирования предпринятых модификаций
равноправными участниками.
Требование консенсуса: модификация принимается
только после согласования со всеми членами
(участниками).
46
Co4: Совместная разработка
согласованных баз знаний
Для того, чтобы этот подход работал, участники проекта
не должны непосредственно модифицировать базу
знаний, а только свое личное рабочее пространство. В
Co4 каждый участник рассматривается системой как
база знаний. Для построения согласованной базы
знаний индивидуальные базы знаний должны быть
связаны вместе. Базы знаний организуются в дерево,
чьи листья являются пользовательскими базами знаний
и чьи промежуточные вершины называются групповыми
базами знаний. Каждая групповая БЗ представляет
знания, согласованные между его сыновьями.
47
Co4: Совместная разработка
согласованных баз знаний
Групповая БЗ посылает своим подписчикам сообщения
об изменениях, принятых всеми, и просьбу прислать
комментарии (должны ли эти изменения быть
зафиксированы или нет).
Когда подписчики достаточно уверены в своих порциях
знаний, они могут представить их своей групповой БЗ.
Это предложение затем представляется другим
подписчикам как запрос на комментарий. В ответ,
пользователи должны дать один из ответов: «принять»
(accept), когда они считают, что предложенные знания
должны быть интегрированы в согласованную БЗ,
«отвергнуть» (reject), когда так не считают, и «запрос,
вызов» (challenge), когда они предлагают другое
изменение.
48
Метод (KA)2
Метод (KA)2 получен из опыта разработки онтологий в
Инициативе по Аннотированию Знаний при Сообществе
Приобретения Знаний.
Его цель - смоделировать общество приобретения
знаний, используя онтологии, разработанные
совместными усилиями группы людей, находящихся в
разных местах, используя одни и те же шаблоны и
язык.
49
Метод (KA)2
Онтология (KA)2 формирует базис для аннотирования
WWW документов общества приобретения знаний для
того, чтобы сделать возможным интеллектуальный
доступ к этим документам.
Текущая концептуальная модель онтологии (KA)2
состоит из связанных онтологий: онтология
организаций, онтология персон, онтология проектов,
онтология публикаций, онтология событий,
онтология направлений исследования и онтология
продуктов (результатов) исследования.
50
Метод (KA)2
В совместный распределенный процесс разработки
онтологий были вовлечены два типа людей:
агенты-разработчики (Ontopic agents) и
агенты-координаторы (Ontology coordinating agents).
Агенты-разработчики входили в исследовательскую
группу, которая имела глубокие знания по некоторым
областям интереса. Существовало 15 групп агентовразработчиков, каждая из которых фокусировалась на
определенной тематике онтологии КА (ПЗ). Их целью
было учредить согласованную онтологию сообщества
ПЗ, поэтому они должны были иметь распределенное
видение тематики, которую представляли.
51
Метод (KA)2
Большинство онтологий (KA)2 (организаций, проектов,
людей, публикаций, событий и исследовательских
продуктов (результатов исследования)) были прямо
разработаны агентами-координаторами. Чтобы
построить эти онтологии, они создали свою
концептуальную структуру и определи главные понятия,
таксономии, отношения, функции, атрибуты и аксиомы,
делегировав добавление экземпляров сообществу.
Разработка Онтологии направлений исследования
была выполнена совместно агентами-разработчиками,
которые являлись экспертами в определенных
областях исследований, и агентами-координаторами.
52
Метод (KA)2
Первая версия онтологии (KA)2 была построена на
Flogic, который является языком описания онтологий,
используемым в Ontobroker.
Чтобы сделать полную онтологию доступной всему
сообществу через Ontolingua Server, было принято
решение транслировать ее в Ontolingua.
Трансляция онтологии из Flogic в формат Ontolingua
была выполнена автоматически транслятором, который
являются частью ODE.
53
Метод (KA)2
Чтобы облегчить разработку Онтологии направлений
исследования, агенты-координаторы распределили
шаблоны среди агентов-разработчиков, которые
использовали электронную почту (e-mail) для своих
внутренних коммуникаций, а также посылки своих
результатов агентам-координаторам.
Онтология была построена из знаний, полученных
через шаблоны. Когда агенты-координаторы получили
все порции онтологий от агентов-разработчиков, они их
объединили вместе. В это случае процесс интеграции
не был трудным, так как все агенты-разработчики,
использовали одни и те же образцы.
54
Методы и методологии слияния
(объединения) онтологий
Слияние онтологий стало ключевым пунктом в последние годы.
С одной стороны, слияние онтологий на этапе проектирования
очень важно, так как слияние компаний или организаций в одну
может привести к слиянию их онтологий. Необходимость слияния
нескольких онтологий может быть вызвана и желанием получить
другую онтологию с лучшим качеством.
С другой стороны, слияние онтологий во время работы
приложения может быть очень критичным. Фактически, онтологии
становятся все более общими в WWW, где они обеспечивают
семантику для аннотирования Web-страниц. Более того,
разнородность информации в WWW может спровоцировать
появление различных онтологий в близких областях. Такое
разнообразие должно сосуществовать с взаимодействием между
системами. Возможность совмещения разнообразия с общностью
должно установить отображение между онтологиями и слияние их
во время исполнения
55
Методы и методологии слияния
(объединения) онтологий



ONIONS
PROMPT
FCA-Merge – метод слияния онтологий
снизу-вверх
56
ONIONS
ONIONS (ONtological Integration Of Naïve Sources) [Gangemi
et al., 1999] – это методология для концептуального анализа
и онтологической интеграции и слияния онтологий.
ONIONS ориентирован на обеспечение всесторонней
аксиоматизации, прозрачной семантики и онтологической
глубины для терминологии некоторой области, которая
должна быть интегрирована или слита (объединена).
57
ONIONS
Онтологический анализ и слияние терминологий
выполняется в две фазы:
(1) реинжиниринг данных, по которым строится онтология,
(2) слияние онтологии.
Фаза реинжиниринга включает извлечение,
форматирование, анализ и формализацию концептуально
релевантных данных из источников.
Извлечение и форматирование выполняется сверткой
релевантных данных после предварительной оценки их
типов данных.
Анализ состоит в выявлении подразумеваемых значений
терминов.
Проанализированные данные формализуются на
логическом языке.
58
ONIONS
Слияние означает создание новой онтологии, имеющей
такое же экстенсиональное покрытие (объем), что и
сливаемые онтологии, но различное количество и/или
распределение свойств и аксиом (различное содержание).
Если онтологии некоторой области построены или
усовершенствованы без учета базовой онтологии, то
количество работы, которая должна быть выполнена при их
слиянии достаточно велико. Фактически, без базовой
онтологии мы можем использовать в качестве стратегий
слияния только структурное распределение аксиом и
схожесть наименований, так как слияние не базируется на
некотором разделяемом множестве отношений и понятий.
59
ONIONS
ONIONS требует использования фундаментальных и
ядерных онтологий.
Методология ONIONS обеспечивает руководство по
оцениванию синонимии, категоризации и полисемии.
Стратегия слияния ONIONS переиспользует приемы из
анализа области для выделения аксиом из «голых» аксиом.
В частности, ситуация с легковесными онтологиями и
простыми таксономиями, связывающими множества
понятий с одним и тем же родительским понятием без
какого-то явного, общего критерия, подобна ситуации с
интегрируемыми онтологиями, которые еще не слиты.
60
ONIONS
Приемы извлечения синонимов, обогащения таксономии и
управления полисемией.

Извлечение синонимов. Синонимия встречается, когда
два понятия с разными именами имеют одну и ту же
подразумеваемую модель и область значений. Может
использоваться несколько эвристик для выделения
кандидатов в синонимы, основанных на подобии имен,
лексической смежности (встречаемости), разделении
свойств и использованием доступных лексических
ресурсов. Синонимы обычно включаются в множество
лексических реализаций понятия.
61
ONIONS

Обогащение таксономии. Любые два родственных понятия,
полученные в результате логической интеграции двух онтологий,
должны быть разделены явно, чтобы они не могли быть слиты как
синонимы. В общем случае без предобработки методом анализа
области, предложенным ONIONS, задача была бы очень трудной,
так как подразумеваемое значение двух разнородных
родственных понятий может быть даже разделено между двумя
непересекающимися понятиями фундаментальной или ядерной
онтологий. В этом случае мы можем потребовать, чтобы для
любого множества родственных понятий из онтологий
разнородных областей, концептуальное различие между каждым
из них было выведено и формализовано аксиомами, которые
переиспользуют (если возможно) отношения и понятия, уже
существующие в библиотеке.
62
ONIONS

Управление полисемией. Полисемия встречается, когда два
понятия с перекрывающимися или раздельными мыслимыми
моделями имеют одно и то же имя (или являются парой принятых
синонимов). Кроме омонимии, может появиться несколько видов
концептуальной полисемии. Наиболее интересным случаем
является множественная категоризация, когда понятие C
является синонимом понятия C1 в L, при этом C относится к
категории понятия D в L , а C1 относится к категории понятия D1 в
L. Этого не может случиться, когда синонимия порождается
исходя из общих свойств определенных (описанных) понятий.
Во всех этих случаях схема аксиом строится заново или может
быть получена путем уточнения существующей аксиомы в
базовой онтологии. Соответственно, C и C1 будут соотнесены с
различными понятиями внутри схемы аксиом.
63
ONIONS
ONIONS начался в 1993 г. как альтернатива методологии
конструирования онтологий снизу-вверх, применяемой в проекте
GALEN. Затем ONIONS применялся для построения ядра
медицинской онтологии (ON9), онтологической разработки UMLS
репозитория, к интеграции клинических управленческих
стандартов и позже к web-каталогам, правовому регулированию,
банковскому обслуживанию, переиспользованию WordNet,
слиянию терминологии по рыбной ловле.
Хотя ориентация ONIONS была сохранена, в последние годы
было уточнено использование фундаментальных и ядерных
онтологий путем разрешения широкой аксиоматизации верхнего
уровня, в результате были созданы онтология DOLCE и схема
аксиом для разработки ядерной онтологии.
64
PROMPT
PROMPT [Noy and Musen, 2000] – это алгоритм для слияния и
выравнивания онтологий, который создавался как
полуавтоматический.
Он был реализован как плагин Protégé-2000 и выполнял
некоторые задачи автоматически и направлял пользователя
при выполнении других задач, в которых требовалось его
вмешательство. Этот плагин определяет возможные
противоречия (несовместности) в текущем состоянии
онтологии, которые могут быть результатом действий
пользователя, и предлагает пути исправления этих
противоречий. PROMPT основывается на весьма общей
модели знаний и поэтому может быть применен для
различных платформ.
65
PROMPT
PROMPT принимает во внимание различные характеристики
исходных онтологий, чтобы сделать предположения и найти
противоречия:




имена классов и слотов (если фреймы имеют похожие имена и
одинаковый тип, тогда они являются кандидатами на слияние);
иерархия классов (если пользователь сливает два класса, и
PROMPT уже обнаружил, что их суперклассы похожи, тогда он
будет иметь больше доверия к этому предложению);
присоединение слота к классу (если два слота из различных
онтологий присоединяются к сливаемому классу и их имена,
фасеты и значения фасетов подобны, эти слоты являются
кандидатами на слияние);
фасеты и значения фасетов (если пользователь сливает два
слота, тогда их ограничения на область значений являются
кандидатами на слияние).
66
PROMPT
Дополнительно, чтобы обеспечить предложения
пользователю, PROMPT идентифицирует противоречия. Вот
некоторые из них:




конфликты имен (более, чем один фрейм с одним тем же
именем),
висячие ссылки (фрейм ссылается на не существующий фрейм),
избыточность в иерархии классов (более чем один путь от
класса к его родителю, отличному от корня),
ограничения на значения слота, которые противоречат
наследованию на классах.
67
PROMPT
Характеристики, перечисленные выше, используют графовую
структуру онтологии, чтобы ограничить пространство: мы
можем перемещаться по вершинам графа только на один или
два шага.
AnchorPROMPT является расширением PROMPT, которое
сравнивает графовые структуры в большем масштабе. Оно
принимает на вход множество указателей (якорей) – пар
связанных термов, определенных пользователем и
автоматически выполняет лексическое сопоставление.
AnchorPROMPT трактует онтологию как граф с классами в
качестве вершин и слотами в качестве связей (дуг). Алгоритм
анализирует путь в подграфе, ограниченном указателями, и
определяет, какие классы появляются в подобных позициях
на подобных путях. Вероятно, эти два класса и представляют
семантически подобные понятия.
68
PROMPT
69
FCA-Merge – метод слияния
онтологий снизу-вверх
FCA-Merge – это метод для слияния онтологий, который
использует подход снизу-вверх, предлагающий глобальное
структурное описание процесса слияния.
Для исходных онтологий он извлекает экземпляры понятий из
заданного множества текстовых документов, релевантных
рассматриваемой области, применяя методы обработки
текстов на ЕЯ.
Основываясь на извлеченных экземплярах, он применяет
математически обоснованные методы из области
формального анализа понятий (Formal Concept Analysis),
чтобы построить решетку понятий как структурный результат
метода FCA-Merge.
Полученный результат исследуется разработчиком онтологий
и транслируется в новую онтологию.
70
FCA-Merge – метод слияния
онтологий снизу-вверх
Процесс слияния онтологий состоит из трех шагов:
(1) извлечение экземпляров и вычисление двух формальных
контекстов K1 и K2,
(2) применение базового алгоритма FCA-Merge, который
выводит общий контекст и вычисляет решетку понятий, и
(3) интерактивная генерация финальной онтологии, основанная
на решетке понятий.
71
FCA-Merge – метод слияния
онтологий снизу-вверх
Для получения хороших результатов входные данные
должны удовлетворять следующим допущениям.
Первое, документы должны быть релевантны каждой из
исходных онтологий.
Второе, документы должны покрывать все понятия исходных
онтологий. Понятия, которые не покрыты, должны
интерпретироваться вручную после выполнения процедуры
слияния (или множество документов должно быть расширено).
Третье, документы должны разделять понятия достаточно
хорошо. Если два понятия, рассматриваемые как различные,
всегда появляются в одних и тех же документах, FCA-merge
будет отображать их в одно и то же понятие в целевой онтологии
(если это решение не блокируется инженером знаний). Если
такая ситуация случается слишком часто, инженер знаний
должен добавить дополнительно документы, которые бы
способствовали разделению понятий.
72
Спасибо за терпение!
73