16 июня 2009 года  команда CO-ODE выпустила релиз одного из самых популярных редакторов онтологий  Protege 4.

В качестве основных возможностей этого редактора заявляют поддержку OWL 2, возможности прямого подключения к подсистемам логического вывода Pellet и FaCT++.

Более подробно о функциональных возможностях релиза Protege 4 можно почитать здесь!

Загрузить релиз можно отсюда!

Скриншот релиза Protege 4:

Лирическое отступление

AgentOWL – небольшая java библиотека, разработанная для поддержки RDF/OWL моделей для Jade агентов.

Здесь используется описание модели знаний агента(generic agent model), основанная на пяти основных элементах: Resources, Actions, Actors, Context и Events. Поддерживается обмен сообщениями в формате RDF/OWL, включение полученной информации в модель.

Read the rest of this entry »

В рамках этой инициативы планируется перевести интерфейс редактора онтологий Protege на украинский и русский языки.

Первым шагом стал перевод базового интерфейса Protege и подготовка неофициального файла локализации на русском языке.

Подробнее

На данной странице будут публиковаться неофициальные файлы локализации для редактора онтологий  Protege.

Важно! Файлы локализации для редактора онтологий Protege переведены добровольцами специально для сайта  SHCHERBAK.NET. Эти файлы протестированы на работоспособность c Protege 3.4  RC1, но никаких гарантий, что файл будет у вас работать мы не даем. И самое-самое – вы используете все на свой страх и риск, осознавая, что локализация осуществлялась не разработчиками Protege…

Файл локализации для базового интерфейса Protege 3.4  RC1 (на русском языке):

Скачать

Скачать архив

Скриншот руссифицированного интерфейса  Protege 3.4  RC1:

Процедура установки файла локализации:

1. В папке, где установлен  Protege, найдите файл  protege_text.properties и сделайте его резервную копию!

2. Замените файл protege_text.properties скачанным с сайта SHCHERBAK.NET

3.  Запустите protege.

---

Замечания к переводу оставляйте в комментариях!

Среди планов – локализация интерфейса Protege на украинском языке и, есстественно, плагины…

Захотите добавить сюда свой файл локализации для плагинов или Protege, пишите…(адрес в контактах)

---

надеюсь, эта информация будет вам полезной=)

немного об авторе review здесь

JeromeDL [Semantic Digital Library] – семантическая электронная библиотека, основанная на технологиях Semantic Web (MarcOnt, FOAFRealm  и HyperCuP). Для развертывания JeromeDL  необходимо установить Java 2 EE.

Последнее обновление этого проекта – 20 июня 2008 г.

OWLAPI – JAVA-интерфейс для обработки web-онтологий на языке OWL.  Поддерживаются версии языка OWL – 1.0, 1.1, 2.0. OWLAPI может использоваться как машина логического вывода в приложениях Java.
Последнее обновление – 17 апреля 2008г.

Docgen -  плагин для редактора онтологий Protégé для быстрого экспорта содержимого онтологии в различные форматы (html, pdf, fo…).
Последнее обновление – 25 февраля 2008г.

OntoBridge – библиотека  классов  Java для легкого управления онтологиями. OntoBridge основан на Jena, работает с локальными/удаленными онтологиями OWL, поддержживает логический вывод с помощью Pellet/DIG.
Последнее обновление – 7 марта 2008г.

DODDLE-OWL – средство разработки онтологий для Semantic Web. DODDLE-OWL позволяет работать с существующими онтологиями. Главной особенностью данного проекта является возможность полуавтоматического построения таксономии онтологии на основе документов!
Последнее обновление – 4 ноября 2008г.

JOFS -  проект нацеленный на разработку owl-онтологии для хранения мета-информации о файлах и документах! В рамках проекта также разрабатывается расширяемый интерфейс для управления подобной онтологией.
Последнее обновление – 8 июня 2008г.

ORE (Ontology Rule Editor) – платформо-независимое  приложение для управления логическим выводом.  В рамках проекта разрабатывается как прикладной интерфейс для написания своих приложений, так и GUI для тестирования правил.
Последнее обновление – 8 ноября 2008г.

oBrowse -  web- базированное приложение для просмотра онтологий на языке OWL. Для отображения онтологий используется древовидное представление. Для разработки oBrowse использовались средства Protege-API и JSF.
Последнее обновление – 26 января 2008г.

Ответ на это прост, если не учитывать проблемы, которые я освещал в одном из предыдущим постов.

Cначала давайте определимся, что будем понимать под приложением Semantic Web.

Итак, если приложение построено с использованием таких средств Semantic Web, как XML,  RDF, OWL, SPARQL, то такое приложение будем называть приложением Semantic Web первого типа.

В случае, если приложение реализует идеи Semantic Web, как концепции,  тогда такое приложение назовем приложением Semantic Web второго типа.
Read the rest of this entry »

OWL 2 расширяет OWL Web Ontology Language небольшими, но полезными возможностями, а именно исправлены ошибки предыдущих версий, добавлена возможность простейшего метамоделирования, расширена поддержка типов данных и аннотаций. Кроме того, добавлены новые свойства и конструкторы, поддеживающие ограничение на количество вхождений (qualified cardinality constructors).

OWL 2 обратно совместим с OWL 1.

На сегодняшний день над спецификацией OWL 2 продолжается работа, но черновой вариант OWL 2 уже поддерживается бета-версией редактора онтологий Protégé 4.

УДК 519.178, 519.711
Павлов Д.А.

Введение

Развитие базы знаний – закономерный и постоянный процесс. Его влияние на все системы, связанные с этой базой знаний, трудно переоценить. Ввиду чрезвычайно больших размеров
объекта исследования, его анализ без помощи автоматических и автоматизированных СППР является трудоемким и малоэффективным.

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

Учитывая складывающиеся тенденции в применении онтологий, исследуемые онтологии по-умолчанию являются нечеткими.

Связанные задачи

Наиболее близкой задачей, к той, которая описывается в данной статье, является автоматическая локализация и устранение противоречивости статической онтологии (Prt_s).
Среди важных достижений в данном направлении необходимо отметить: обобщенные подходы к разрешению противоречивости [1], подходы анализа работы блоков логического вывода
(БЛВ) [2,3]. Первые решают комплексную задачу выявления причин возникновения противоречивости и поиска соответствующего шаблона решения, в то время как вторые демонстрируют цепочку фактов, приведших БЛВ к выводу о противоречивости. Наиболее полно достижения в направлении анализа БЛВ отражены в разработке SWOOP [4]. Не смотря на значительные достигнутые результаты этих работ, в них не уделяется должного внимания непосредственно процессу развития онтологии, являющегося корневым элементом появления противоречивости. Данная статья рассматривает вопросы статической противоречивости нечеткой онтологии Prt_sf, а также динамической противоречивость Prt_d.

Другим родственным разделом затронутой проблематики являются работы связанные с нечеткими онтологиями и их семантическими особенностями [5]. В работах рассматриваются и обосновываются возможности введения в онтологию понятий нечеткого отношения, а также показывается значительное повышение уровня выразительности таких онтологий в сравнении с четкими.

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

Данная работа является логическим продолжением ряда работ посвященных интенсивному и экстенсивному развитию онтологических структур [8,9] и принимает все определения и соглашения принятые там.

Постановка задачи

Пусть существует некоторая онтология Ont наблюдаемая в условиях интенсивного развития

где Ont_i – онтология в момент времени t_i, характеризующий момент создания данной онтологии, I конечный неотрицательный номер версии Ont.

Известно, что развитие dev(Ont_i, Ont_i+1) является результатом совместной работы N различных, возможно не связанных между собой групп, занимающихся поддержкой данной онтологии.

Тогда, непосредственно переход Ont_i -> Ont_i+1 является простейшим элементом, на базе которого можно объективно оценить результирующий вклад всех N групп.

Существует вероятность того, что нескоординированные действия либо брак допущенный в работе приведут к появления фактов противоречивости (Prt_sf и Prt_d) в результирующем развитии.

Необходимо:

- проанализировать процесс возникновения Prt_sf и Prt_d, оценить их влияние на общую семантику онтологии;

- разработать методы и алгоритмы автоматической локализации и устранения Prt_sf и Prt_d;

Ограничения и требования:

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

- выразительность онтологий ограничим дескриптивными логиками (ДЛ) с конечным логическим выводом.

Основные понятия:

(Четкая) онтология Ont есть конечный набор триплетов <s,p,o> , где s – субъект, p – предикат и o – объект.

Нечеткая онтология Ont_f есть конечный набор триплетов [<s,p,o>,m], для которых определена функция принадлежности m, характеризующая степень существования данного триплета. При m = 1, триплет считается всегда истинным, при m=0 – незаданным.

Таким образом, всякая Ont является частным случаем Ont_f.

Для ДЛ любого класса противоречивость есть существования объекта эквивалентного пустому множеству.

Для класса логик, в которых определено понятие отрицания предиката (ØP), можно утверждать следующее: для некоторых предикатов pÎP, где P полный набор
предикатов онтологии, существует ÎP такое, что <s,p,o>Ç<s, ,o>
= Æ для всех s и o, или другими словами предикат-отрицание. Например, равен – неравен, пересекается – не пересекается.

Противоречивость Prt_s – есть свойство онтологии, характеризующее онтологию, в которую одновременно входят по крайне мере два утверждения, <s,p,o> и <s, ,o>.

Противоречивость нечеткая Prt_sf – есть свойство онтологии, характеризующее онтологию, в которую одновременно входят по крайне мере два утверждения,
[<s,p,o>,m₁], [<s, ,o>,m₂], где m₁ , m₂ ³ g, где g – настраиваемый порог достоверности.

Отметим, что для четкого пространства состояний онтологии g равен 1.

Динамическая противоречивость Prt_d – есть свойство развития dev(Ont_x, Ont_y), описывающая состояние при котором существует хотя бы один такой набор [<s,p,o>,m₁] Î Ont_x,
[<s, ,o>,m₂] Î Ont_y и m₁ , m₂ ³ g, при чем Ont_x, Ont_y по-отдельности непротиворечивы.

Блок логического вывода (БЛВ, reasoner) – подсистема логического вывода, позволяющая проверить истинность, ложность либо неопределенность некоторой аксиомы в рамках заданной онтологии. Также БЛВ зачастую используются для построения полного набора аксиом на базе существующей онтологии.

Сложность логического вывода. Говорить о сложности логического вывода из онтологической базы знаний в общем виде не возможно, в виду того, что различная степень выразительности приводит к значительным различиям в сложности. Сложность может варьироваться от полиномиальной до невычисляемой. Учитывая принятые ограничения
на выразительность, а также существующие реализации БЛВ, а также мы рассматриваем сложность ДЛ SHIF_f [5], SHOIN [10] и sROIQ с простыми типами [11]. Важно
отметить, что выбранные ДЛ достаточно выразительны для создания противоречивых утверждений.

Семантика противоречивой онтологии

Всякая работа с онтологической базой знаний подразумевает использование правил логического вывода при получении некоторого ответа на некоторый запрос. Так как в формальной логике из ложной посылки можно получить любой ответ, а противоречивость онтологии говорит о наличии по крайне мере одной ложной аксиомы в составе онтологии, то любая противоречивость потенциально грозит неадекватностью работы всей онтологической базы знаний.

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

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

Семантика динамической противоречивости заключается в том, что некоторые элементы онтологии приобретают такие свойства, которые бы привели к противоречивости в предыдущей версии онтологии. Очевидно, что факт динамической противоречивости менее фатален для функционирования онтологической базы знаний, но все же он говорит о некоторой специфичности данного перехода меду версиями.

Можно выделить наиболее ряд основных причин возникновения динамической противоречивости.

1. Вследствие устранения существовавшей ошибки.

2. Вследствие ошибки ввода.

3. Вследствие несоответствия понятий.

4. Вследствие ошибки в цепи логического вывода.

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

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

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

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

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

Избыточность и неполнота в условиях противоречивости

Всякое изменение онтологии сопровождается возникновением свойств неполноты Npl и избыточности Iz [12].

Рассмотрим простейший случай возникновения динамической противоречивости. Пусть существует следующий набор аксиом, формирующий онтологию Ont₁: заданы классы A и В, при чем A несовместен с B, и задан класс C, являющийся подклассом А. Исходя из правил логического вывода, B и C несовместны. Пусть произошло развитие онтологии до Ont₂, в которой класс С стал подклассом B, тогда C теперь несовместен с A. Имеем два набора придающие развитию dev(Ont₁, Ont₂)свойство динамической противоречивости Prt_d:

и;

и .

Очевидно, что элементы, образующие пары противоречивости, формируют также и попарное возникновение неполноты и избыточности.

С₁ = {,}

C₂ = {,}

или в нормализованном виде

С₁ = {,,,}

C₂ = {,,,}

Npl_С = 1, Iz_C = 1

Важно отметить, что динамическая противоречивость, в отличие от статической, сопровождается
одновременным присутствием свойств Npl и Iz.

Теорема 1. Всякое развитие dev(Ont_x, Ont_y), обладающее свойством динамической противоречивости, обладает свойствами неполноты и избыточности.

Доказательство теоремы 1. Пусть существует свойство Prt_d для развития dev(Ont₁,Ont₂), тогда по определению 3 будет некоторый набор [<s,p,o>,m₁] Î Ont₁, [<s, ,o>,m₂] Î Ont₂. Предположим что для данного развития dev Npl = 0, тогда в онтологии Ont₂ должно присутствовать утверждение [<s,p,o>,m₁] Î Ont₂ – но тогда Ont₂ обладает свойством статической противоречивости Prt_s, что противоречит определению 3. Следовательно, Npl ¹ 0. Аналогично доказывается присутствие Iz.

Отметим, что обратная связь свойств отсутствует.

Оценка присутствия динамической противоречивости Prt_d в условиях перехода dev(Ont_x, Ont_y) сопряжена с интеграцией версий Ont_x, Ont_y, что не всегда приемлемо.

Например, некоторая онтология Ont состоит из двух крупных подразделов Ont₁ и Ont₂, которые разрабатываются. Пусть Ont₁ подвергся сильным изменениям, в то время как Ont₂ изменился поверхностно. Важно оценить при заведомой конфликтности одного подраздела плавность перехода другого. При чем явно эти разделы не отделимы. Учитывая выбранный уровень выразительности онтологий, скорость работы БЛВ экспоненциально зависит от размеров входных данных [10,11].
В связи с этим эффективным решением является автоматическое разбиение онтологии на модули, аналогичные тем которые формируются при экстенсивном развитии. Для независимой оценки Ont₂ необходимо, чтобы выполнялось условие nezav(Ont₂, Ont₁), таким образом, необходимо привести онтологию к виду аддитивного экстенсивного развития [8].

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

Аксиома. Некоторый элемент A онтологии Ont принадлежит ядру Ont_core , тогда и только тогда, когда fun(Iz_A, Npl_A)<a, где Iz_A избыточность элемента при переходе dev, Npl_A - неполнота, a – настраиваемый порог.

Порог a может быть скорректирован в соответствии с набором отчетов {Rep}. Например, a = min(a_i) при необходимости выделения наименьшего и наиболее точного
ядра, либо a = (åa_i)/|Rep| при необходимости выявления наибольших всплесков противоречивости.

Разрезание онтологии может привести к появлению несвязных подграфов, как в Ont_core, так и в Ont_env. Потеря связности является признаком потенциально опасных изменений и требует обращения дополнительного внимания на сохранение семантики объектов, подпадающих под описание различными подграфами.

Также разрезание может привести к «выкалыванию» элементов подразделов. Например, в слабо измененном ядре некоторый элемент сильно изменился, но не повлек за собой изменений связанных с ним элементов. Для уменьшения такого влияния введем порог S на размер графа перемещаемого в Ont_env, где S минимальное число связных
элементов. Увеличивая S – оператор будет требовать большей независимости подразделов онтологии.

Кривая эффективности порога связности S (Рисунок 1) имеет 2 значимые точки S₁ и S₂, где S₁ – наиболее полное разделение, а S₂ – порог, после которого онтология остается единым целым.

Рисунок 1 – Кривая эффективности порога связности

Автоматическое устранение динамической противоречивости

Рассмотрим концептуальный алгоритм обработки случаев возникновения динамической противоречивости (Рисунок 2).

Рисунок 2 – Алгоритм итеративного устранения динамической противоречивости

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

Для этого блок проверки адекватности включает следующие функции:

1. Рекурсивный расчет значений критериев неполноты и избыточности для всех элементов онтологии;

2. Механизм сравнения отчетов разработчиков с полученными значениями критериев неполноты и избыточности;

3. Блок нечеткого логического вывода о присутствии ошибки в развитии.

В случае если принимается решение о наличии ошибки в развитии, включается блок локализации факта Prt_d, который в свою очередь состоит из:

4. Механизм разрезания онтологии на Ont_core и Ont_env;

5. Оценка статической целостности Ont_core.

6. Приведение в состояние целостности Ont_core.

7. Механизм последовательного подбора несовместных аксиом из Ont_env;

8. Блок логического вывода, подтверждающий несовместность.

Далее после установления противоречивой аксиомы используется:

9. Аналитический блок логического вывода, позволяющий использовать всю цепь логического вывода, говорящую о несовместимости аксиом;

10. Фаззификационный блок, уменьшающий степень противоречивости.

Вся система тесно взаимодействует с интерфейсом управления оператора онтологии.

Рассмотрим подробнее каждый пункт.

Пункт 1 детально рассмотрен в [12], суть которого заключается в расчете двух числовых значений критериев адекватности Npl(A₁,A₂) и Iz(A₁,A₂) для каждого элемента A₁ входящего в версию онтологии Ont₁ и соответствующего элементу A₂ входящего в версию онтологии Ont₂, где dev(Ont₁, Ont₂) = true. Полученный набор значений позволяет перейти из пространства групп в метрическое пространство, что дает возможность использовать более мощный математический аппарат.

Пункт 2 сравнивает расчетные средние значения Npl и Iz с обобщенными значениями глубины изменения, предоставляемыми с новой версией онтологии.

k = max[max[avg(Iz), avg(Npl)] – ch(Rep), 0] (1)

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

k = max[max[avg(Iz), avg(Npl)] – def_ch, 0] (2)

Второй механизм является менее предпочтительным, но более универсальным.

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

Res = min[m(x_i)]|i=1,N, m(x_i) = 1- k_i. (3)

Результат Res является переменной функции решения об автоматическом запуске процессов локализации и устранения противоречивости (Рисунок 3)

, (4)

где a является настраиваемым порогом противоречивости.

3 – Функция принадлежности онтологии классу противоречивых

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

Пункт 4 детально рассмотрен выше, имея низкую вычислительную сложность, может быть выполнен в режиме реального времени множество раз. Это дает возможность эффективно
визуализировать на уровне интерфейса оператора результаты разрезания, что упрощает плавную подстройку параметров разрезания.

Также данный этап может выполняться в полностью автоматическом режиме.

Проверка статической целостности 5 в Ont_core осуществляется путем проверки всех аксиом онтологии на предмет равенства пустому множеству, при помощи существующих БЛВ.

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

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

1) аксиомы, входящие в Ont_env, которые составлены из предикатов имеющих отрицание, сортируются по значениям критериев Npl и Iz;

2) в отдельном списке они сортируются по близости к ядру по принципу, если для аксиомы A<s,p,o> s или o входят в ядро, то близость равна Near_core(А) = 1, если s или o входят в аксиому A₁ близость которой уже известна Near_core(А₁) = n, то Near_core(А) = n+1, в случаях конфликтов выбирается наименьшая близость; таким образом, чем меньше значение близости, тем меньше аксиом нужно добавить, чтобы необходимая аксиома стала связна с ядром;

3) в результате этих двух сортировок для проверки выбирается наиболее близкая из наиболее неадекватных аксиом, вместе с ней в ядро включается набор связных с ней аксиом. Ширина данного набора определяется параметром W, который можно настраивать из интерфейса оператора.

В 8 этапе выбранная выше аксиома проверяется на предмет близости пустому множеству с помощью правил вывода БЛВ. Достижение порога противоречивости, инициирует запуск механизма устранения противоречивости. Запуск данного механизма контролируется оператором, но может быть выполнен и в автоматическом режиме.

На этапе 9 используется механизм дебага описанный в [4], а также его расширения, который позволяет выделить цепь аксиом, порождающих противоречивость. Полученный набор передается в следующий блок.

Блок 10 решает задачу снижения уровня противоречивости, которая представляется в формальном виде как поиск оптимума между снижением противоречивости и неувеличением общих показателей Npl и Iz онтологии. Снижение уровня противоречивости достигается за счет уменьшения степени уверенности некоторых из аксиом цепочки противоречивости.

Выбор аксиомы А, подлежащей «ослаблению» осуществляется с помощью следующей эвристики:

1) АÎOnt_Env

2) минимальное число объектов Obj должно описываться данной аксиомой A, N®min, A Î Obj_i | i=1,N,

3) если одна и та же аксиома входит в разные цепи противоречивости, то она является предпочтительной для «ослабления».

Ослабление аксиом производится по следующей формуле

, (5)

где m₀ и m₁ значения функции принадлежности существования ослабляемой аксиомы в версиях 0 и 1 соотвественно.

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

Прикладное решение задач

Рассмотрим процесс работы предложенных решений на прикладных объектах.

Исследование производилось на онтологии информационных потоков предприятия Ont_Inf, разработанной на языке OWL[14] с уровнем выразительности DL с использованием нечетких предикатов. Данная онтология являлась экстенсивным развитием онтологии SWEET[15], которая в свою очередь является экстенсивным расширением базовой онтологии OWL.

Используя синтаксис принятый в [9],

imp(Ont_Inf, {Ont_OwlDL, Ont_Sweet})=1 и Struct = <{ Ont_Inf, Ont_OwlDL, Ont_Sweet }, {imp(Ont_Inf, {Ont_OwlDL, Ont_Sweet})}>.

В ходе исследования изменению подлежали две составляющие онтологической структуры Ont_Sweet, а также Ont_Inf

D_Inf = {<Ont_Infi, t_i>_i}|i=0..3, D_Sweet = {<Ont_Sweetj, t_j>_j}|j=0..2

Отметим, что развитие D_Inf происходило в условиях зависящих от данного исследования, в то время как D_Sweet – полностью независимое развитие.

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

, MRI(t)=MRI=const,

Онтологии Ont_OwlDL и Ont_Sweet являются четкими, в то время как Ont_Inf – нечеткая.

4 – Обобщенная схема онтологической структуры Struct

Рассмотрим переход dev(Ont_Inf0, Ont_Inf1) который сопровождался значительным уточнением понятий бухгалтерии, а также незначительными коррективами в области кадровой информации. Это было отмечено в отчетах разработчиков как Rep_Skl = {ch = 0, imp = 0}, Rep_Buh = {ch = 0,5, imp = 0,8}, Rep_Kadr = {ch = 0,1, imp = 0,1}.

Данные отчета Rep_Buh свидетельствуют о том, что некоторые понятия были значительно переопределены, и при этом эти изменения могут и должны повлечь коренные изменения в логическом выводе. Данные же отчета Rep_Kadr говорят о том, что внесенные изменения поверхностны, и всякие их последствия не должны сильно отразиться на результатах логического вывода.

Одним из важнейших изменений в разделе Buh фактически было переопределение понятий «дебет» и «кредит». В версии 0 данные два понятия состояли в отношении «несовместности»,
в то время как в версии 1 данное отношение было удалено. Таким образом, появилась возможность одновременно у одного объекта указать, что он является «дебетом» для одного объекта хозяйственной деятельности и «кредитом» для другой. Это, во-первых, уменьшило количество фактически дублирующихся объектов, а во-вторых, увеличило семантическиесвязи между объектами хозяйственной деятельности. Таким образом, в Ont_Inf1 появились аксиомы, которые в Ont_Inf0 были бы заведомо противоречивыми.

Проследим работу системы проверки адекватности.

При расчете значений критериев Iz и Npl получены следующие данные:

Таблица 1 – Значения критериев неполноты и избыточности для развития Ont_Inf

Имя онтологии	Критерий	max	Avg
OntInf	Iz	1	0,2
	Npl	1	0,4
Buh	Iz	1	0,23
	Npl	1	0,6
Skl	Iz	0,3	0,03
	Npl	0,2	0,01
Kadr	Iz	1	0,19
	Npl	0,2	0,01

Сравним полученные значения с отчетами Rep по формуле (1):

k_Buh = 0.1, k_Skl = 0.03, k_Kadr = 0.09.

Тогда, блок логического вывода над результатами сравнения проверяет, принадлежит ли данное решение к классу непротиворечивых (3,4):

Prt (max[k_i]) => [0,1]

В данном развитии принадлежность к классу непротиворечивых решений 0.7 (при a =0.66).

В автоматическом режиме решение принимается, что версия онтологии применима.

Выберем из интерфейса оператора решение о дальнейшем анализе развития.

При разрезании онтологии получаем связное ядро Ont_core и набор аксиом образующий Ont_env. Ont_core целостна.

Переходим к подбору потенциально противоречивых аксиом. Первой аксиомой в очереди является аксиома A = <”дебет”, “disjointWith”, “кредит”>. Для простоты примера выберем значения переменной W = 0.

При проверке выявляем, что Ont_Core+A – противоречива.

Цепи противоречивости включают следующие аксиомы:

{А, <obj1, isA, “дебет”>, <obj2, isA, “кредит”>, <obj1, “equals”, obj2>},

{А, <obj3, isA, “дебет”>, <obj4, isA, “кредит”>, <obj3, “equals”, obj4>},

{А, <obj5, isA, “дебет”>, <obj6, isA, “кредит”>, <obj5, “equals”, obj6>}.

Исходя из эвристик блока 10 аксиома А подлежит ослаблению. [A`,0.5]

При таком утверждении уровень противоречивости снижается до допустимого.

Рассмотрим переход dev(Ont_Sweet0, Ont_Sweet1) который сопровождался уточнениями и исправлениями в ряде модулей. Так как данная
онтология является внешней, то отчеты разработчиков не поставлялись при ее изменении.

Повторим операции анализа

Таблица 2 – Значения критериев неполноты и избыточности для развития Ont_Sweet

Имя онтологии	Критерий	max	Avg
OntSweet	Iz	1	0,14
	Npl	1	0,09
Units	Iz	1	0,16
	Npl	1	0,3
Human Activities	Iz	0	0
	Npl	0	0
Other	Iz	1	0,15
	Npl	1	0,04

Принимая значениями по умолчанию def_ch = 0 рассчитаем значения k. k_Units = 0.3, k_HA = 0, k_Other = 0,15.(

В данном развитии принадлежность к классу непротиворечивых решений 0 (при a =0.66). Таким образом, автоматически переходим к фазе выявления противоречивости.

Разрезаем онтологию на Ont_Core и Ont_Env. При первом разрезании в Ont_Env содержится ряд одиночных аксиом. Повышаем порог s до 1. После этого получаем Ont_Env, состоящую из 3 модулей: 1 – степени в единицах измерений, 2 – изменения в данных о биосфере, 3 – изменения данных об элементах Земли.

nAd(Ont_Core) = 1. Это происходит в связи с тем, что поменялся ряд функциональных значений свойств некоторых объектов. Например, поменялся ряд численных и строковых
значений. Разрешение этого конфликта выполняется на уровне интерфейса оператора, путем использования в качестве истинных значений второй версии.

Итак, имеем модифицированное целостное ядро Ont`_Core.

{TODO look SWEET}

Рассмотрим развитие Ont_Inf в аспекте развития dev(Ont_Sweet0, Ont_Sweet1), а также в аспекте скорректированного развития dev(Ont_Sweet0, Ont`_Sweet).

Наблюдается значительное снижение значений критериев неадекватности.

Выводы

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

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

Уточнено понятие противоречивости для онтологического развития, что дает возможность снизить сложность поиска противоречивых аксиом онтологий.

Оценена верхняя граница сложности алгоритмов используемых в рамках разработанного метода оценки, которая позволяет говорить о приемлемых временных затратах системы
анализа, на различных этапах работы.

Список литературы

1. Peter Haase, Frank van Harmelen, Zhisheng Huang, Heiner Stuckenschmidt, and York Sure A Framework for Handling Inconsistency in Changing Ontologies // Lecture Notes
in Computer Science, Springer-Verlag, Germany, 2005, pp. 353-367

2. Bijan Parsia and Evren Sirin and Aditya Kalyanpur, Debugging owl ontologies //The 14th international world wide web conference (www2005), Chiba, Japan, May
2005.

3. Wang, H. Harridge, M. Rector, A. Drummond, N. Seidenberg, J. Debugging OWL-DL Ontologies: A Heuristic Approach // Lecture Notes in Computer Science, Springer-Verlag,
Germany, 2005, pp. 745-757

4. Aditya Kalyanpur, Bijan Parsia, James Hendler A tool for working with web ontologies// In proceedings of the international journal on semantic web and information systems, vol. 1, no. 1, jan – march, 2005

5. Umberto Straccia, A Fuzzy Description Logic for the Semantic Web // Fuzzy Logic and the Semantic Web, Elsevier, 2006, pp. 73-90

6. Stuckenschmidt, H. Klein, M. Integrity and Change in Modular Ontologies // International Joint Conference on Artificial Intelligence, USA, 2003, Vol. 18,
pp. 900-908

7. Fikes, R. Farquhar, A. Rice, J. Tools for Assembling Modular Ontologies in Ontolingua // Proceedings Of The National Conference on Artificial
Intelligence, USA, 1997, N 14, pp. 436-441

8. Павлов Д. Экстенсивное развитие онтологических структур // «Бионика интеллекта», Харьков, №2(63), 2005 г. С 91-97.

9. Кучеренко Е., Павлов Д. Модель интенсивного развития онтологий // “АСУ и приборы автоматики”, Харьков, №135, 2006 г. С. 4-12

10. Stephan Tobies. Complexity results and practical algorithms for logics in Knowledge Representation. PhD Thesis, LuFG Theoretical Computer Science, RWTH-Aachen,
Germany, 2001, 173 p.

11. I Horrocks, O Kutz, U Sattler The even more irresistible SROIQ // Principles of Knowledge Representation and Reasoning (KR’2006). http://www.cs.man.ac.uk/~okutz/sroiq-TR.pdf

12. Кучеренко Е., Павлов Д. О проблемах выявления неполноты и избыточности информации в онтологическом пространстве // Прикладная радиоэлектроника, Т.4, №2,
Харьков, 2005 г., С. 175-179

13. SOFT COMPUTING

14. OWL (W3C)

15. SWEET

ДК 519.178, 519.711
Кучеренко Е.И., Павлов Д.А.

Введение

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

Некоторые из существующих подходов работы с развивающейся онтологией [1] ориентированы на внесение дополнительной метаинформации в ходе разработки онтологии и последующем семантическом анализе этих данных. Такой подход эффективен при строгой формальной разработке онтологий и не достаточно применим к стихийно развивающимся онтологическим структурам. Исследования [2-3], ориентированные на анализ процесса развития, изучают широкий набор базовых изменений в онтологии, но не уделяют внимания неявным последствиям изменений. В работе [4] предлагается метод поддержки адекватного развития онтологии, основанный на проверке целостности текущей версии.

Подходы [1-4], не смотря на то, что имеют ряд важных результатов, не достаточно полно формализуют процесс развития онтологии. Также в этих работах отсутствует возможность количественной оценки версий с точки зрения целостности, что не позволяет решать задачи максимизации и минимизации адекватности.

Работа, посвященная модульности онтологии в распределенных системах [5], ярко отразила тенденции в прикладных задачах использования онтологий, но оставила без внимания процессы изменения структуры в ходе доработки.

Разработка PROMPT [6] в рамках проекта Protégé[7] предлагает особый подход сравнения версий, но в ней не отражаются подходы использования внешних ссылок онтологии, а также не предусмотрено использование нечетких онтологий [8].

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

1. Постановка задачи.

Пусть существует онтологическая структура (ОС) представленная набором связанных нечетких онтологий [9]

Struct = <MO,MRI>,

где MO = {Ont_i} – множество всех онтологий входящих в ОС, MRI = {RI_j}, конечное множество всех отношений импорта RI заданных на данной ОС.

Пусть элементы ОС подвержены изменению с течением времени. Изменения носят дискретный характер и вносятся в соответствии с синтаксисом выбранного языка представления онтологий. Такого рода изменения онтологий будем именовать интенсивным развитием.

Существует ряд основных типов различий существующих внутри онтологий одной предметной области:

• терминологические отличия: для одних и тех же объектов используются различные имена AB, A^I=B^I;

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

• кодировочные: правильные значения свойств могут отличаться, могут использоваться различные шкалы
  ;

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

• уровня детализации: одна онтология более детально описывает предметную область, нежели другая Ont₁  Ont₂.

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

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

Тогда необходимо:

• разработать обобщенную модель интенсивного развития онтологии;

• интегрировать разработанную модель с моделью экстенсивного развития ОС [9];

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

1. Элементы интенсивного развития ОС

Всякая онтология Ont может быть изменена с течением времени. Введем кортеж D, описывающий этапы развития Ont, при чем элементы кортежа представляются парой: онтология и момент времени создания данной онтологии. Интенсивное развитие есть

(1)

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

Введем функции, связывающие онтологию и время в соответствии с развитием D. Учитывая дискретность развития

, (2)

где функция значения онтологии в момент t для развития D.

, (3)

где функция обратная (2).

Введем отношение версии такое, что

если , то , (4) и наоборот,

если , то .

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

Определение 1. Сравнимыми онтологиями Ont_x и Ont_y мы будем называть такие онтологии, для которых выполняется отношение близости

near(Ont_x,Ont_y) = true. (5)

Работая с нечеткими онтологиями, а также при необходимости получения большей выразительности понятия близости, в ряде случаев имеет смысл применения непрерывного значения близости near(Ont_x,Ont_y)  [0,1]. Фактически, оценка близости двух онтологий – это не тривиальная задача, и она является предметом отдельных, дальнейших исследований в данной области. В статье для вычисления данного условия будем использовать упрощенную функцию, сравнивающую мощность пересечения двух версий и сумму мощностей их различий

, (6)

где |Ont| – мощность онтологии.

Декомпозиция онтологии

Исходя из исследований [10], онтология может быть отображена в виде ориентированного графа. Тогда пусть онтология Ont есть некоторый граф

Ont = <N,E>, (7)

где N – узлы онтологии, E – отношения между узлами (ориентированные дуги).

В рамках онтологии будем выделять три подграфа

1. T-граф – концептуальная часть онтологии. На данном графе узлами являются классы T и отношения R, а дугами базовые
отношения, вводимые грамматикой данного языка онтологий.

2. А-граф – объектный граф. Его узлами является множество объектов онтологии, дуги – отношения между объектами, как вводимые грамматикой данного языка, так и введенные на T-графе отношения R.

3. ТА-граф – связующий между концептуальным и объектным. В качестве узлов содержит классы T и объекты A, принадлежащие этим классам, в качестве дуг здесь выступают отношения принадлежности объекта классу. Данный граф является двудольным.

Ont = T+ A + TA (8)

Принимая во внимание содержательную часть трех подграфов графа (8) часть его узлов в ряде случаев выступает в качестве дуг (отношения R), независимое рассмотрение описанных подграфов по отдельности снимает данную коллизию.

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

Необходимо отметить, что декомпозиция (8) не является единственно возможной. В ряде источников [11] TA- и А-графы рассматриваются как один. Также возможна и более глубокая декомпозиция, зависящая от специфических особенностей онтологии. Предлагаемое разложение универсально и легко осуществляемо в рамках существующих прикладных реализаций структуры онтологии.

Подграфы онтологии неравнозначны, для них характерны зависимости и подчиненные связи.

Отметим, что независимым элементом A и от элемента B онтологии Ont – это такой элемент, для которого верно:

A^I = const, , и записывается ,

где A^I интерпретация данного элемента онтологии с помощью некоторой функции интерпретации ,значит, что B может принимать любые значения, возможные в рамках данной онтологии.

Тогда один подграф G₁ зависит от другого G₂, nezav(G_1, G₂) = false, тогда и только тогда когда . В таком случае можем строить иерархию подграфов аналогично иерархии, возникающей при интенсивном развитии ОС.

Атомарность развития

При развитии всякого графа (7) будем различать изменение структуры узлов N и структуры связей E графа онтологии. Изменение структуры узлов N для поставленной задачи может состоять только из удаления и добавления узлов inc(N), dec(N).
Изменение структуры связей также заключается в добавлении и удалении связей inc(E), dec(E), а также изменении значения функции принадлежности ch(E).

Отметим, что изменение структуры связей может напрямую зависеть от изменения структуры узлов. Так как всякая связь E соединяет два узла, то удаление одного из этих узлов автоматически влечет удаление связи E. Такое удаление будем называть подчиненным.

dec(N) {dec(E)_i}

Для сохранения общности, пусть добавление на данном этапе развития всех связей E, использующих добавленный узел N, также будем называть подчиненным.

inc(N){inc(E)_i}

Тогда единичный этап развития онтологии можно описать как кортеж, состоящий из пяти обособленных элементов

dev(Ont₁,Ont₂)= <inc_N,dec_N,inc_E, dec_E,ch_E>, (9)

где inc_N, dec_N – множества добавленных и удаленных узлов с подчиненными связями, inc_E, dec_E – множества добавленных и удаленных независимых связей, ch_E – множество измененных связей.

Отметим что для четкой онтологии ch_E всегда .

Нормализация

Известно, что одну и ту же семантику можно передать с помощью онтологии на одном и том же языке различными структурами. Введем операцию нормализации norm графа онтологии Ont

Ont* =norm(Ont)= <N,E*>|Ont =<N,E> EE*,E*/E= {R_infi} , (10)

где Ont* –результирующая онтология, E*– измененная структура дуг графа онтологии, R_inf– неявные отношения, полученные путем логического вывода из уже имеющихся знаний.

В существующих решениях в области нормализации онтологий преобладает подход вычисления неявно заданных знаний [11, 12].

Утверждение 1. Если онтологии, полученные в результате нормализации (10), равны, то исходные онтологии равны.

если Ont*_x = Ont*_y, где Ont*_x =norm(Ont_x), Ont*_y =norm(Ont_x), то Ont_x = Ont_x.

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

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

1. Гибридизация интенсивного и экстенсивного развития

Рассмотрим некоторую распределенную ОС Struct = <MO, MRI>.

Пусть всякой Ont_i  MO соответствует некоторое развитие D_i (1), i=1,I.
Предположим, что для всякого значения времени t мы можем построить соответствующую структуру импортов MRI(t).

Рисунок 1 – Пример схемы гибридного
развития ОС

Тогда

, (11)

является гибридным развитием ОС. Пример такого вида структуры отражен на Рисунке 1.

Рассмотрим главные особенности структуры (11).

В целом зависит от двух групп переменных и . При фиксации одной из групп переменных наблюдаем следующее:

При выполнении условия

, MRI(t)=MRI=const, (12)

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

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

, =MO=const, (13)

Гибридное развитие ОС может содержать разрывы в функциях значения онтологии. Например, представим, что некоторая онтология Ont была в ходе развития заменена двумя (или более) онтологиями Ont₁ и Ont₂, при чем Ont = Ont₁  Ont₂.

Из функции (6) очевидно, что .

В то же время .

Таким образом, мы наблюдаем разрыв развития D и появление развитий D₁ и D₂ (Рисунок 2) (по оси ординат комплексная оценка адекватности изменения версии Ad [13]).

D-> D₁,D₂.

Очевидно, что возможна и обратная ситуация

D₁,D₂ ->D.

В таком случае будем говорить об обобщенном интенсивном развитии,

, (14)

где J(t) – количество онтологий в момент времени t, относящихся к развитию D. Развитие (14) является частным случаем общего гибридного развития.

Тогда (2) необходимо обобщить до

. (15)

Рисунок 2 – Разветвление при интенсивном развитии

В процессе развития ОС возможно возникновение неадекватности nAd.

Рассмотрим случай когда

Struct = <{Ont₁, Ont₂},imp(Ont₁, Ont₂)>.

Пусть импортируемая онтология Ont₂ развивается интенсивно:

D_ont2 = <{Ont₂₁,t₁},{Ont₂₂,t₂}>

Предположим что некоторый узел A, AOnt₁, зависит от элемента B, BOnt₂₁, nezav (A,B)= false.

Пусть для изменения версии dev(Ont₂₁, Ont₂₂) удален узел B, dec(B) = true.

Тогда в момент t₂ имеем

nezav (A,B) = false | Struct(t) = <{Ont₁, f _Dont2(t₂)}, imp(Ont₁, Ont₂₁)>, B=U,

где U – универсум. То есть утверждается зависимость A от некоторого абсолюта, что семантически не верно.

Cостояние развития

Struct (t₂)= <{Ont₁, Ont₂₁},imp(Ont₁, Ont₂₁)>

будем называть неадекватным и записывать

nAd(Struct(t₂)) = true. (16)

Тогда если nAd(Struct(t)) = true, где , то время t, будем называть временем неадекватности.

Важно различать адекватность состояния nAd(Struct(t)) (16) и адекватность развития Ad(Ont₁,Ont₂) [13]. Состояние может быть неадекватным в силу избыточности либо неполноты в структуре. В то же время при развитии мы можем получать полностью адекватную структуру, но она будет настолько отличаться от своей предыдущей версии, что данное развитие будет рассматриваться как неадекватное.

Определение 2. Если nAd(Struct(t)) = false, tt₀, то развитие такой структуры мы будем называть всюду структурно адекватным.

Такого рода структуры могут создаваться в условиях строгих правил разработки и являются эталоном развития распределенной онтологической структуры.

Определение 3. Если nAd(Struct(t)) = false, tt₀, то развитие такой структуры – частично структурно адекватное.

Развитие такого рода обуславливается глубоким распараллеливанием процесса разработки, который не позволяет синхронизировать структуру на всех этапах.

Определение 4. Если nAd(Struct(t)) = true, tt₀, то развитие такой структуры – структурно неадекватное.

Такого рода структуры наиболее точно описывают развития структур в Интернет, например FOAF [15].

Для случаев частичной структурной адекватности либо структурной неадекватности важным является поиск верхней границы адекватного состояния. Фиксируя некоторое время развития t онтологии Ont, мы можем обнаружить неадекватность структуры. Тогда применение предыдущих версий онтологий, связанных с Ont может привести к адекватности всей структуры.

Введем операцию получения предыдущих версий онтологии, аналоги которой в литературе именуются rollback (англ. откат)

rb(f_D(t₁))= f_D(t₂), (17)

где t₂<t₁, t₂ =max(t), f_D(t₁) f_D(t).

Пусть

rbⁱ(Ont) = rb₁(rb₂(…(rb_i(Ont))…))| i0, rb⁰(Ont)= Ont.

Принимая во внимание (17)

rb({Ont_i}) ={{rb(Ont₁), Ont₂,…, Ont_I},{ Ont₁,rb(Ont₂),…,Ont_I},…,{Ont₁,Ont₂,…,rb(Ont_I)}}. (18)

Определение 5. Если существует некоторый набор {j_i}, j_i  min, такой, что nAd(Struct(t)) = false, где , то структура является субадекватной.

При чем, для всякой онтологии, для которой соответствующее значение из набора {j_i} равно 0, то данная субадекватная структура является для нее верхней границей адекватности.

Существует некоторый набор {j_i} такой, что nAd(Struct) = false .

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

Следует отметить, что множество ОС могут не обладать свойством адекватности, а также субадекватности. Не смотря на это, оценка адекватности их развития также необходима. Тогда перейдем к численной мере независимости онтологических ресурсов

nezav(A,B)  [0,1], при чем (nezav(A,B)=true)  (nezav(A,B)=1).

Таким образом, зависимость ресурсов можно проранжировать. Отметим, что такой переход также необходим для адекватной работы с нечеткой информацией. Тогда nAd(Struct) [0,1], что позволяет выполнять операции минимизации неадекватности структуры.

1. Алгоритмизация операций с моделями и рекомендации к практической реализации

Оценка адекватности развития произвольной ОС является многогранной и многоуровневой задачей. Рассмотрим наиболее общие и выразительные алгоритмы работы с развивающейся ОС (11).

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

Алгоритм поиска верхней границы адекватности развивающейся ОС.

Пусть существует развитие , для него необходимо определить все верхние границы адекватности для онтологии Ont в момент t_k.

Шаг 1. Установка входных значений: входной ОС Struct и онтологии Ont из этой ОС для которой осуществляется поиск (D_Ont = <Ont,t>), добавление Struct в очередь структур Queue.

Шаг 2. Текущая ОС Struct равна первому значению в очереди Queue. Из Queue удаляем первое значение.

Шаг 3. Проверка неадекватности (16) состояния текущей Struct: nAd(Struct(t)), если nAd(Struct(t)) = true переход на Шаг 4, иначе переход на Шаг 7.

Шаг 4. Выполняем операцию rollback (17) для набора онтологий текущей структуры. rb(Struct) = {Struct_i}

Шаг 5. Добавляем в очередь Queue все {Struct_i}, при чем проверяем, что такие значения Struct еще не помещались в очередь.

Шаг 6. Переход на Шаг 2.

Шаг 7. Добавляем текущую Struct в результирующий список Res.

Шаг 8. Если очередь Queue не пуста переход на Шаг 2,иначе переход на Шаг 9.

Шаг 9. Возвращение списка адекватных структур Res.

Шаг 10. Останов.

Онтологическое представление знаний сопряжено с внушительными требованиями к вычислительным ресурсам, а именно к объемам памяти v и времени расчета t. В связи с этим любые алгоритмические решения в этой области требуют проверки на предмет сложности. Рассмотрим алгоритм на предмет верхних границ вычислительной сложности. Важнейшими параметрами в нем являются размерность ОС и длительность оценки адекватности текущей структуры ad_t(Struct).

Оценим верхнюю границу сложности поиска адекватного состояния структуры по критерию временных затрат,

C_RB_t = k_rb_t* (J_i)*ad_t(Struct), (19)

где J_i – количество версий i онтологии, k_rb_t – параметры системы.

Очевидно, что большое количество элементов ОС порождает взрыв размерности C_RB_t.
Для предлагаемого алгоритма целесообразно использование предобработки, позволяющей снизить размерность области поиска. Такая предобработка должна включать выбор заведомо правильных версий онтологий в ОС. Здесь целесообразно сохранение результатов вычислений в качестве метаинформации онтологии. Такое сохранение позволит
значительно сократить размерность каждого из J_i только до того числа, которое еще не было ни разу обсчитано.

Оценим верхнюю границу сложности поиска адекватного состояния структуры по критерию затрат памяти C_RB_v,

C_RB_v = k_rb_v* I *ad_v(Struct), (20)

где I – мощность экстенсивной составляющей развития ОС, ad_v(Struct) – затраты памяти необходимые для вычисления адекватности, которые включают наборы элементов онтологий, которые имеют внешние ссылки, k_rb_v – константа параметров среды.

Предлагаемая модель во многом базируется на подходах концепции Semantic Web, которая предполагает разностороннее использование онтологий. Это позволяет говорить об объективном отражении теоретических разработок в практической реализации модели в рамках данной концепции.

Проследим поведение модели на существующей ОС [16]. Проект SWEET (Semantic Web for Earth and Environmental Terminology) ориентирован на использование
научными сотрудниками различных направлений. Для интеграции множества разнородной информации в проекте используется ряд связных онтологий в формате OWL. Отметим, что в данный момент проект находится в стадии активной разработки, и элементы интенсивного развития присутствуют на всех уровнях структуры.

Рассмотрим процесс интенсивного развития базовой онтологии ОС SWEET, которой является онтология “units”. Она содержит информацию о физических единицах измерения. Рассмотрим ее в трех версиях D_units= <{units₁, t₁}, {units₂,t₂}, {units₃,t₃}>

Известно, что переход от версии 1 к версии 2 был вызван требованием возможности добавления базовых пропорций:
«процент», «промилле» и др. Также в изменение версии вошло изменение представления понятия «ампер» в виде строки. Множество добавленных объектов отражено количественными характеристиками строки RD₁₂ Таблицы 1.

Переход от версии 2 к версии 3 сопровождался меньшим количеством изменений, но они носили более сложный характер. Так, в частности, появился ряд новых связывающих отношений между уже существовавшими объектами, а также были исправлены некоторые строковые значения. Наиболее ярко сложный процесс изменения отражен столбцом А строки RD₂₃ Таблицы 1.

Таблица 1 – Кортежи развития подграфов (9) онтологии units.

	T	TA	A
RD12	<0, 0, 0, 0, 0>	<13N+91E, 0, 0,0, 0>	<13N+14E, 1N+1E, 0, 0, 0>
RD23	<0, 0, 0, 0, 0>	<1N+10E, 0, 0, 0, 0>	<3N+4E, 1N+1E, 2E, 1E, 0>
RD13	<0, 0, 0, 0, 0>	<14N+101E, 0, 0, 0, 0>	<16N+18E, 2N+2E, 2E, 1E, 0>

Очевидно, что строка RD₁₃ эквивалентна поэлементному сложению строк RD₁₂ и RD₂₃, что говорит о линейности развития D_units, а также о независимости изменений.

Рассмотрим гибридное развитие ряда онтологий, входящих в структуру SWEET.

D_units = <{units₁, t₁}, {units₂,t₂}, {units₃,t₃}>

D_bio= <{bio₁,t₁},{bio₂,t₂}>

D_{hum_act}= <{hum_act, t₁}>

D_{mat_th}= <{mat_th, t₁}>

D_earth= <{earth, t₁}>

D_space=<{space₁,t₁},{space₂,t₃}>

D_num=<{num₁,t₁},{num₂,t₃}>

D_prop=<{prop₁,t₁},{prop₂,t₃}>

D_subst =<{subst₁,t₁}, {subst₂,t₃}>

D_time =<{time, t₁}>

Итак, мы наблюдаем онтологическую структуру на трех этапах развития:
t₁, t₂ и t₃. Отметим, что близость (5) для всех частных развитий выполняется. Проверим неадекватность (16) состояний на всех этапах nAd(Struct(t₁))= false nAd(Struct(t₂))= true nAd(Struct(t₃))= true

Найдем субадекватную структуру для space₂.

Расчет показывает, что такого развития не существует. Следовательно развитие space₂ не адекватно.

Найдем субадекватную структуру для subst₂.
Struct = <{units₂,bio₂,hum_act, mat_th, earth, space₁,num₁,prop₂,subst₂,time }, MRI>.

Данные разрозненные примеры прикладного использования могут быть интегрированы и задействованы в единой системе управления онтологией (СУО), которая будет использовать не только текущее состояние онтологии, но и предыдущие ее версии.

Выводы

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

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

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

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

Список литературы

1. Heflin J., Pan Z. A Model Theoretic Semantics for Ontology Versioning // ISWC 2004, LNCS 3298, 2004, P. 62–76.
2. Heflin J. Towards the Semantic Web: Knowledge Representation in a Dynamic, Distributed Environment // PhD thesis,
   University of Maryland, 2001. 137 p.
3. Klein M. Change Management for Distributed Ontologies // PhD thesis, Vrije Universiteit, 2004. 206 p.
4. Haase P., Stojanovic L. Consistent evolution of OWL ontologies // In Proceedings of the Second European Semantic Web
   Conference, Heraklion, Greece, 2005. http://www.aifb.uni-karlsruhe.de/WBS/pha/publications/owlevolution05eswc.pdf (12.04.2006)

5. Stuckenschmidt H., Klein M. Integrity and change in modular ontologies. In Proc. IJCAI’03, Acapulco, Mexico, 2003.

6. Noy N. F., Musen M. A. PROMPT: Algorithm and Tool for Automated Ontology Merging and Alignment // Seventeenth National
   Conference on Artificial Intelligence (AAAI-2000), Austin, TX, 2000. http://dit.unitn.it/~p2p/RelatedWork/Matching/SMI-2000-0831.pdf (12.04.2006)

7. Noy N. F., Sintek M., Decker S., Crubezy M., Fergerson R. W., Musen M. A. Creating Semantic Web Contents with Protege-2000 // IEEE Intelligent Systems, 2001, 16(2). P. 60-71.

8. Кучеренко Е.И., Павлов Д.А. Некоторые аспекты анализа развития нечетких онтологий. //Искусственный интеллект. Донецк. 2005. C.
   162-169.
9. Павлов Д.А. Экстенсивное развитие онтологических структур // Бионика интеллекта: научн.-техн.журнал. Харьков, 2005. (в печати)
10. Resource Description Framework (RDF) // http://www.w3.org/RDF/ (08.12.2005)
11. Haarslev V., Moeller R. RACER System Description // in Proceedings of the International Joint Conference on Automated
    Reasoning, IJCAR’2001, 2001. http://www.sts.tu-harburg.de/~r.f.moeller/racer/papers/2001/HaMo01a.pdf (13.04.2006)
12. Sirin E., Parsia B., Grau B. C., Kalyanpur A., and Katz Y. Pellet: A practical owl-dl reasoner. // http://www.mindswap.org/papers/PelletJWS.pdf (08.12.2005)
13. Павлов Д.А. О подходах к контролю адекватности развития онтологий. // Тезисы доклада на международной научно-технической конференции
    «Искусственный интеллект. Интеллектуальные и многопроцессорные системы». Дивноморское. 2005. Т.2. С. 400 403.
14. Кучеренко Е.И., Павлов Д.А. О проблемах выявления неполноты и избыточности информации в онтологическом пространстве //Прикладная
    радиоэлектроника, Т.4, №2, Харьков, 2005 г, С. 175-179.
15. FOAF Vocabulary Specification //http://xmlns.com/foaf/0.1/ (13.04.2006)
16. Raskin R. Guide to SWEET Ontologies // http://sweet.jpl.nasa.gov/guide.doc (13.04.2006)

Павлов Дмитрий

Цель работы заключается в устранении критичности процесса поиска в распределенной онтологии. Поставленная цель, ввиду тенденций роста применения технологии Semantic Web, является актуальной и требующей практической реализации.

Введение

За последние несколько лет IT индустрия сильно шагнула в развитии автоматического поиска, сбора и обработки информации. Одним из ведущих направлений этой отрасли является технология Semantic Web[1], продвигаемая W3 консорциумом. Среди последних значительных достижений данной технологии спецификация языка описания онтологий OWL[2]. Вместе с появлением такого мощного инструмента возник ряд практических задач его непосредственного внедрения и применения. Решенными задачами на сегодняшний день являются: визуальные среды разработки онтологии[3,4]; спецификация агентного взаимодействия по средством метаописания механизмов передачи и обработки данных[5]; проверка формальной целостности онтологии[6] и пр. В данной работе предполагается использование этих решений.

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

Цель работы заключается в устранении критичности процесса поиска в распределенной онтологии. Поставленная цель, ввиду тенденций роста применения технологии Semantic Web, является актуальной и требующей практической реализации.

1 Постановка задачи

Изначально онтология предполагается как нечто, что можно разделить на элементы, путем указания ссылок друг на друга. Ввиду практической постановки задачи, условимся, что онтология представлена на языке OWL.

Разделяемая структура рождает задачу поиска элементов при использовании предоставляемых ссылок:

SELECT a FROM uri WHERE resource=»uri#a», (1.1)

где а – элемент онтологии, uri[7] – ссылка на элемент, resource – специфицированный элемент RDF[8].

Помимо простого нахождения элемента онтологии, сразу заложим требования на более глубокий поиск, а именно – поиск элементов эквивалентных данному:

SELECT a FROM * WHERE a=b, (1.2)

где а и b – элементы онтологии.

Также в углубленный поиск должна входить возможность дополнения тройки субъект-предикат-объект, при отсутствии одного из элементов, что тоже является поиском:

SELECT a FROM * WHERE [a, R, b], (1.3)

где [a, R, b] – тройка субъект-предикат-объект, а – один из недостающих элементов тройки.

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

Таким образом, необходимо предложить алгоритм либо ряд алгоритмов онтологического поиска, выполняющие 1.1, 1.2, 1.3, а также их взаимные вариации в условиях распределения данных в сети. Представленные алгоритмы должны базироваться на общих принципах языка OWL и быть обоснованными с точки зрения оптимальности.

2 Онтологический поиск в контексте OWL

Определимся с основными понятиями, которыми мы будем оперировать.

2.1 Сеть

Ont = Σ Stor_i, i=1,n, (2.1)

где Ont – распределенная онтология, Stor_i – часть онтологии, находящаяся в i хранилище данных, n – число хранилищ.

Рисунок 2-1 Пример топологии сети

Сеть (Рис. 2-1), в которой функционирует онтология, будем рассматривать как направленный граф, обладающий не всеми дугами. Узлами графа являются хранилища данных, таким образом число узлов – n. Дуги графа – ссылки, которыми обладают хранилища.

Допущение 1. Пусть в графе нет обособленных вершин.

Этим допущением мы исключаем случаи, когда не возможно вернуть наиболее полный ответ, что противоречит условиям поставленной задачи.

Допущение 2. В топологии сети не присутствуют циклы. В случае, если каким-либо путем запрос будет адресоваться узлу, сформировавшему его, он будет игнорироваться.

Дуги между узлами возникают в момент указания внешних ссылок в элементе онтологии. Помимо определения узла-соседа непосредственно из имени документа вводится форсированное объединение, когда известно, что разные документы хранит один и тот же узел. В этом случае в данном узле помещается объект, в котором указан набор пространств имен, обрабатываемых другим узлом.

Таблица 2.1 – Формирование дуг сети.

URI	Узел-сосед	Элемент
http://www.w3.org/2002/07/owl#Class	http://www.w3.org/2002/07/owl	class
http://www.w3.org/2001/XMLSchema#float http://www.w3.org/2001/XMLSchema#string	http://www.w3.org/2001/XMLSchema	float string
rmi://127.0.0.1/1.owl#a rmi://127.0.0.1/2.owl#b	Форсировано объедине\\нный – localhost	a b

2.2 Поиск

Теперь определимся с непосредственным результатом выполнения глобального поиска, то есть фактическим результатом работы системы, функцией search(Ont, query₀).

Определение 1. Search(Ont, query₀) возвращает наиболее полно описанную элементарную сущность языка OWL, отвечающую базовому запросу query₀.

Под элементарной сущностью OWL мы понимаем класс, свойство либо объект, а под запросом query₀ мы подразумеваем один из запросов указанных в 1.1 – 1.3.

Наиболее полное описание достигается только в результате работы с онтологией целиком. Чтобы не решать задачу поиска силами одного сервера обозначим порядок дифференциации нагрузки в рамках отдельных серверов, введем понятие локального поиска local_search(Stor_i, query_k).

Определение 2. Под локальным поиском мы будем понимать поиск, ограничивающийся ресурсами i хранилища данных.

Введем операцию-обработчик результатов process(Stor_i, result), где result - результат выполнения функции глобального либо локального поиска. Данная операция отвечает за преобразование результатов локального поиска в каскад запросов к серверам-соседям, узлам к которым ведут дуги от данного узла. По возврату данных от серверов-соседей может вновь инициироваться локальный поиск, но уже с учетом полученной информации.

Ввиду допущений 1 и 2, а также топологии сети, введем возможность перемещения поиска из узла, в котором происходит обработка информации, в узлы-соседи:

Stor_i ->{Stor_i1, … Stor_ij}, (2.2)

где j число серверов-соседей активного узла.

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

• поиск элемента онтологии по ссылке URI (1.1);
• поиск элемента эквивалентного данному (1.2);
• поиск недостающего элемента тройки N-Triple[8] (1.3).

Рассмотрим каждое направление в отдельности.

Поиск по ссылке (1.1) – тривиальная техническая задача, в которой, имея имя узла и имя искомого на нем объекта, требуется получить развернутое описание объекта.

Поиск эквивалентного элемента (1.2) осуществляется путем использования стандартных рекомендаций для языка OWL[2].

Заполнение недостающего элемента в N-Triple (1.3) будем решать с помощью механизмов RDQL[9].

Не смотря на разобщенность направлений поиска, они тесно связаны. Рассмотрим взаимодействие механизмов поиска (Рис. 2-2).

search(Ont, [a,R,?] ) = Σ search(Ont, [a_m,R_n,?] ), m=1,M; n=1,N, (2.3)

где [a, R, ?] некоторый базовый запроса, a_m эквивалентно a, R_n эквивалентно R, M и N – количество найденных эквивалентностей соответствующему элементу N-Triple.

В 2.3 показано взаимодействие между поиском элементов эквивалентных данному (1.2), когда базовый запрос преобразуется в серию эквивалентных ему, и поиском недостающего элемента тройки (1.3). При формировании, как расширения запроса, так и при поиске недостающих элементов возможно возникает задача поиска по ссылке (1.1). Из сказанного следует, что в данном примере показана логическая связь всех трех элементарных типов поиска.

Рисунок 2-2 Взаимодействие механизмов поиска

3 Межсерверное взаимодействие

В основе межсерверного взаимодействия лежит технология агентного взаимодействия OWL-S[10]. Во-первых, ее использование формализует процесс передачи данных внутри сети, во-вторых, позволяет оставить возможность интеграции системы с внешними пользователями, еще не специфицированными на данном этапе разработки.

Для организации межсерверного взаимодействия специфицируется следующий интерфейс:

1. функция broad(query) преобразующая запрос в список эквивалентных запросов;
2. функция local_search(query) создающая описание элемента OWL по заданному запросу;
3. функция search(query), которая, по сути, является объединением двух предыдущих функций. Ее непосредственно вызывают клиенты.

Используя данный интерфейс, были созданы следующие алгоритмы работы сервера, получившего запрос:

1. Алгоритм 1, простой: сервер расширяет запрос силами своей (локальной) информации и силами всех серверов-соседей, не отличая собственную информацию от чужой, получая, таким образом, наиболее полное расширение для данной сети. Далее для каждого малого запроса выполняет функцию local_search(query) на всех доступных ресурсах. Все полученные ответы соединяются воедино и возвращаются клиенту;
2. Алгоритм 2, с повышенным доверием: сервер расширяет запрос, опираясь исключительно на собственную модель, а затем выполняет функцию search(query) для своей модели и моделей серверов-соседей. Все полученные ответы соединяются воедино и возвращаются клиенту.
3. Алгоритм 3, с транслятором: такой вариант можно назвать гибридным алгоритмом. При локальном расширении запроса используется ряд серверов-соседей исключительно в целях нахождения эквивалентных классов, свойств и объектов. Затем на основании полученной трансляции выполняется функция search(query) для своей модели и моделей серверов-соседей, которые не являются трансляторами.

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

Алгоритм 2 предназначен для случаев, когда каждый из серверов представляет в какой-то степени завершенный ресурс. Таким образом, его область имен, классы и свойства наиболее эффективно применять исключительно к его модели. Скорость выполнения запросов в таком алгоритме выше за счет сокращения числа межсерверных пересылок данных, но качество поиска падает, вследствие того, что часть данных, которые были бы выбраны более широким запросом, утеривается. Таким образом вводим Ограничение 1: ни один сервер такой сети не может не содержать ссылок на сервер, хранящий некоторый объект, эквивалентный данному, иначе данные объекты не будут распознаны как эквивалентные. Такой алгоритм в большей степени подходит Internet поисковикам, которые имеют ссылки на сервера различной принадлежности.

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

Важным аспектом оптимизации межсерверного взаимодействия является кеширование результатов в рамках конкретного поиска. Оно заключается в сохранении результатов выполнения каждого конкретного запроса. Благодаря такой организации мы предотвращаем ситуацию зацикливания, облегчаем скорость работы при ветвлении сети (как в узлах 1, 2 и 3 на рис. 2-1), а также значительно ускоряем процесс повторного запроса, который может быть инициирован функцией process.

4 Практическая реализация

Рассмотрим пример используя топологию рисунка 2-1.

Информация узла 1.

[3:Мать ID="Маша"]

[2:породил rdf:resource="#Вася"/]

[/3:Мать]

[2:Ребенок ID="Вася"/]

Информация узла 2.

[owl:class rdf:id="Родитель"/]

[owl:class rdf:id="Ребенок"/]

[owl:objectproperty rdf:id="породил"]

[rdfs:domain rdf:resource="#Родитель" /]

[rdfs:range rdf:resource="#Ребенок" /]

[/owl:ObjectProperty]

Информация узла 3.

[owl:class rdf:id="Мать"]

[rdfs:subclassof rdf:resource="2#Родитель" /]

[/owl:Class]

[owl:class rdf:about="2#Родитель"]

[owl:equivalentclass rdf:resource="4#Parent"/]

[/owl:Class]

Информация узла 4.

[owl:class rdf:id="Parent"/]

Пусть поступил запрос «Кто Parent Васи?», приведя этот запрос к форме языка запросов получим [?, instanceOf, Parent] и [?, породил, Вася]. Имеем два запроса, обладая информацией по каждому из них мы легко можем сделать пересечение ответов.

Построим модель поиска для первого запроса:

Сервер 1: Расширение: Поиск в локальных данных: Трансляция серверу 2 и 3:		[?, instanceOf, Parent] 0 0
Сервер 2: Расширение: Поиск в локальных данных:		[?, instanceOf, Parent] 0 0
Сервер 3: Расширение: Поиск в локальных данных: Трансляция серверу 2 и 4:	[?, instanceOf, Parent] [?, instanceOf, Родитель] [?, instanceOf, Мать] 0
Сервер 2: Расширение: Поиск в локальных данных:	[?, instanceOf, Parent] – отказ в результате кеширования [?, instanceOf, Родитель] [?, instanceOf, Мать] 0 0
Сервер 4: Расширение: Поиск в локальных данных:		[?, instanceOf, Parent] [?, instanceOf, Родитель] [?, instanceOf, Мать] 0 0
Результат: Общее расширение: Общий поиск: Решение на повторный поиск:		изменилось расширение [?, instanceOf, Parent] [?, instanceOf, Родитель] [?, instanceOf, Мать] 0
Сервер 1: Расширение: Поиск в локальных данных: Результат: Общее расширение: Общий поиск		[?, instanceOf, Parent] [?, instanceOf, Родитель] [?, instanceOf, Мать] 0 [Маша, instanceOf, Мать] изменился результат самого поиска 0 [Маша, instanceOf, Мать]

Для остальных серверов работу рассматривать не будем, так как очевидно, что большая часть запросов будут отказом, а остальные ни к чему не приведут.

Построим модель поиска для второго запроса:

Сервер 1: Расширение: Поиск в локальных данных: Результат: Общее расширение: Общий поиск

[?, породил, Вася] 0 [Маша, породил, Вася] изменился результат самого поиска 0 [Маша, породил, Вася]

Дальнейший поиск результатов не изменит, поэтому не будем рассматривать дальнейший ход событий.

Итак «Кто Parent Васи?» – «Маша».

Предлагаемый пример показывает работу только Алгоритма 1, но базовые элементы этого алгоритма присущи всем остальным предложенным алгоритмам и их детальный анализ не дополнит общей картины.

Выводы

1. В данной статье впервые проводится анализ проблемы организации поиска среди разнесенного в пространстве множества документов OWL. Предложена грань, позволяющая отделить фазу локального и межсерверного поиска, благодаря чему представляется возможным вести оптимизацию использования ресурсов на стратегически разных уровнях работы системы.
2. В работе тесно интегрированы, как различные новые разработки Semantic Web, так и собственные решения.
3. Четко сформулирована цель онтологического поиска. Представлен и логически обоснован процесс формирования ответа на простой запрос.
4. Предложены рекомендации к практическому использованию полученных теоретических результатов в практических приложениях, что определяет практическую значимость выполненной работы.

Литература:

[1] T. Berners-Lee, J. Hendler, and O. Lassila. The Semantic Web. Scientific American, 284(5):34-43, 2001.

[2] D. L. McGuinness and F. van Harmelen. OWL Web Ontology Language Overview. http://www.w3.org/TR/owl-features/ . August 2003. World Wide Web Consortium (W3C) Candidate Recommendation.

[3] Jeremy J. Carroll, Ian Dickinson, Chris Dollin. Jena: implementing the semantic web recommendations. International World Wide Web Conference. pp. 74 – 83, 2004.

[4] W. E. Grosso et al. Knowledge Modeling at the Millennium (The Design and Evolution of Protege-2000). In Proc. of KAW99, 1999.

[5] D. Martin, M. Burstein, O. Lassila, M. Paolucci, T. Payne, and S. McIlraith. Describing Web Services using OWL-S and WSDL. http://www.daml.org/services/owl-s/1.0/owl-s-wsdl.html, October 2003.

[6] Bijan Parsia, Evren Sirin, Aditya Kalyanpur «Debugging OWL Ontologies», In The 14th International World Wide Web Conference (WWW2005), Chiba, Japan, May 2005.

[7] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. 1998.

[8] Graham Klyne, Jeremy J. Carroll Resource Description Framework (RDF): Concepts and Abstract Syntax, http://www.w3.org/TR/rdf-concepts/ 2004

[9] Andy Seaborne, RDQL – A Query Language for RDF HP Labs Bristol http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/ 2004

[10] OWL-S Home Page. http://www.daml.org/services/. 2003.

Автор: Алексей Скороходов

Для создания агента как видно из названия нам понадобится JADE, eclipse и jdk.
После того, как все это извлечено из архивов и установлено, мы можем создать своего первого агента на платформе JADE (Java Agent DEvelopment Framework). Не будем нарушать традиции и первым нашим агентом будет агент «HelloWorld».

Сначала необходимо создать Java-проект нашего агента в среде Eclipse и подключить JADE к этому проекту (см. Рис 1.)

Рисунок 1.

Далее, в полученном проекте в папке src создаем Package c именем «hello». Теперь пришла очередь создать class с именем «HelloWorld» .

Ну и наконец код агента. В нашем случае он будет выглядеть так:


package hello;

import jade.core.Agent;

public class HelloWorld extends Agent
{
public void setup()
{
System.out.println(”Hello Yuhana, my name is : ” +getAID().getName());
}
}

Теперь необходимо подключить JADE (рис. 2 и 3).

Рисунок 2.

Кликаем на кнопку с именем «Add External JARs» и указываем путь к библиотекам JADE, в моем случае это «D:\diplom\stop\bin\jade\lib».
Результат наших действий:

Рисунок 3.

Перед тем как запустить нашего агента необходимо настроить параметры запуска проекта. Это можно сделать выбрав в выпадающем меню «Open Run Dialog», как показано на рис. 4.

Рисунок 4.

Далее, необходимо для «Java Application» создать новую конфигурацию. Во вкладке «Main» присвоим имя нашей конфигурации «test_agents». В «Main class» при нажатии кнопки «Search» выбираем «Boot — jade» и ставил «галочку» в «Include system libraries when searching for a main class» (см. Рис. 5 ).

Рисунок 5.

Далее, во вкладке «Arguments» в «Program argument» добавляем строку «-gui jade.Boot test:hello.HelloWorld»!!!

Ну вот и все, запускаем и получаем агента, выполнившего элементарное действие:

Рисунок 6.

130 «build» редактора онтологий Protege 3.4 beta радует быстрой и стабильной работой.

Под MS Windows новый Protege 3.4 beta показывает просто впечатляющую скорость загрузки… наконец-то, разработчики решили оптимизировать код редактора… За что им огромная благодарность!

Рекомендую обновиться!

Проведённый опрос на сайте SHCHERBAK.NET показал, что многие пользуются редактором онтологий Protege.

OntoEdit, OilEd, SemanticWorks не очень-то пользуются популярностью. Если с SemanticWorks вообщем все ясно (качественный продукт за весьма большие деньги), то с остальными …

Мне лично на их рассмотрение хватило 30 минут … после Protege эти редакторы для моих задач уже не подходили! Хотя редакторы достойные!

SemanticWorks – мощный и стабильный редактор онтологий, причем во многих отношениях лучше Protege… но как мне кажется мог бы стоить меньше.

Меня удивил тот факт, что есть другие достойные альтернативы Protege -

IBM Integrated Ontology Development Toolkit (IODT) – 1 час на регистрацию + 15 минут на установку закончились не успешно! Ничего не могу сказать! Но ODM для Eclipse я пользуюсь, может и IODT достойная вещь! Все таки проекты весьма связаны между собой!

SWOOP – интересный проект, но интерфейс угнетает…

И еще несколько ссылок на редакторы онтологий.

А вы чем пользуетесь?

P.S. В заметке по поводу редакторов высказано мое субъективное мнение и не более того! В опросе несколько человек сказали – мы используем какой-то другой редактор. Неужели это SWOOP?

Если Вам есть, что сказать по поводу редакторов онтологий, пишите в комментарии!

Несколько лет назад открыл для себя замечательный ресурс SourceForge.NET. Меня, как разработчика и исследователя Semantic Web, этот ресурс не мог не заинтересовать. Этот ресурс просто кладезь структурированной информации о различных приложениях, в том числе и приложениях Semantic Web. Одних только проектов, связанных с онтологиями, в нем 185. Плюс 16814 проектов так или иначе связанных с Semantic Web.

Вообщем, этот ресурс может быть весьма полезен исследователям Semantic Web,- как минимум здесь Вы можете посмотреть, какие проекты уже разрабатываются и, главное, на какой стадии разработки находятся. Хочу отметить один немаловажный момент – как бы много Semantic Web проектов не было зарегистрировано на SourceForge.NET, большая часть из них не поддерживается или находится в такой стадии разработки, что просто нельзя их использовать в своих разработках. Но это о грусном!

В качестве положительных моментов – на SourceForge.NET могут быть найдены аннотации существующих Semantic Web проектов и, если повезет, их программная реализация и исходники

Read the rest of this entry »