Сегодня, хочу рассказать вам об одном специалисте в области Semantic Web, работы которого мне очень понравились и, скажу честно, произвели на меня впечатления.
Итак, Наталья Геннадьевна Кеберле, старший преподаватель кафедры информационных технологий Запорожского Национального Университета, член исследовательской группы ISRG (Intelligent Systems Research Group, ZNU).
Некоторые работы Intelligent Systems Research Group (с участием Н. Кеберле)
Проблемы/решения для интеллектуального поиска в Semantic Web с помощью онтологий:
Ermolayev, V.A., Keberle, N.G., Plaksin, S.L., Vladimirov, V.N. (2003)
Capturing Semantics from Search Phrases: Incremental User Personification and Ontology-Based Query Transformation / Извлечение семантики из поисковых фраз: инкрементальная персонификация пользователя и преобразование поисковой фразы с помощью онтологий
Персонификация пользователей на Веб-порталах с помощью профилей – широко известная технология. Как можно построить профиль? Например, «подсматривая через плечо» – т.е. наблюдая за ссылками, которые пользователь открывает. Другой способ – дать возможность пользователю выбрать интересующие его категории из классификатора.
Оба способа не учитывают семантической составляющей в поисковых фразах, которые составляет пользователь. Действительно, одному и тому же ключеслову (роскошный перевод впервые от urbansheep, потом у vvlad) в фразе обычно соответствуют разные контексты, в зависимости от того, какому сообществу принадлежит пользователь, написавший такое ключеслово в поисковой фразе.
В статье предлагается способ инкрементального уточнения профиля пользователя, на основании выставления оценки каждому использованному ключеслову в отношении к некоторой (-ым) онтологиям, доступным на Веб-портале.
Ключеслово/ключефраза получает оценку таким образом:
(ключеслово, <семантическое отношение>, концепт онтологии, степень похожести),
где <семантическое отношение> – одно из таких: «подкласс-суперкласс», «часть-целое», «синоним», «экземпляр».
Таким образом можно попросить пользователя оценить вводимые им слова по степени похожести на один или несколько концептов онтологии. Делать это можно вручную (если точных соответствий в онтологии(-ях) нет), полуавтоматически (лексический разбор ключеслова и поиск лексически близких синонимов и экземпляров в онтологии), автоматически (если пользователь уже оценил похожесть ключеслов).
Для поиска даже в случае отсутствия точных соответствий в профиле предложены несколько правил преобразования и агрегирования, основанных на анализе семантических отношений.
Опубликовано в : M.D. Godlevsky, S.W. Liddle, H.C. Mayr (Eds.):Proceedings of the 2nd International Conference on Information Systems Technologies and its Applications, GI-LNI P-30, pp.9-20 (ISTA’2003), June 19-21, Kharkiv, Ukraine, 2003.
Проблемы/решения для создания семантически интероперабельных информационных систем:
Ermolayev. V., Keberle, N., Shapar, V., Vladimirov, V. (2004)
Ontology-Driven Sub-Query Extraction for Distributed Autonomous Information Resources in UnIT-Net IEDI./ Выявление подзапросов к распределенным автономным информационным ресурсам в инфраструктуре электронного документооборота UnIT-Net.
Проект UnIT-Net применяет архитектуру mediator-wrapper «от начала до конца» для конкретной задачи – организации специфического электронного документооборота между распределенными разнородными автономными провайдерами информационных ресурсов. В основе такой архитектуры лежит использование онтологий: каждый ресурс снабжается онтологией ресурса, а целостное видение предметной области организуется в онтологию медиатора. Отображения «онтология медиатора – онтологии ресурсов» также организованы в виде онтологий маппингов.
При реализации медиаторной архитектуры в распределенной среде для wrappers было решено использовать Web сервисы. Внутренний язык представления онтологий – OWL DL, внутренний язык запросов к онтологиям – RDQL.
Несоответствие терминологии, которую используют для описания своих ресурсов независимые провайдеры, и терминологии, которая понятна пользователю системы, требует решений по разделению и преобразованию исходного запроса пользователя на подзапросы к отдельным ресурсам.
В статье предложен общий алгоритм извлечения подзапросов из исходного запроса пользователя. Пользователь формирует запрос, просматривая и выбирая концепты онтологии медиатора (в которой есть соответствия абсолютно всем концептам онтологий ресурса). Медиатор преобразовывает запрос так, чтобы передать на wrappers ресурсов подзапросы в терминологии этих ресурсов, и затем собирает результаты для показа пользователю.
Опубликовано в: A. Doroshenko, T. Halpin, S. W. Liddle, H. C. Mayr (eds.) Information Systems Technology and its Applications. Proc. 3-d Int. Conf ISTA’2004, July 15-17, 2004, Salt Lake City, Utah, USA, pp. 137-150, GI LNI Vol P-48
Еще одна статья по теме:
Keberle, N., Ermolayev, V., Vladimirov, V., Dzhurinsky, E. (2005)
Visual Semantic Query Formulation and Execution in UnIT-NET IEDI / Визуальное построение семантических запросов и их выполнение в UnIT-NET IEDI.
Требовать от обычного пользователя свободного знания структуры онтологии и языка запросов RDQL неправильно. Удобный визуальный интерфейс, история запросов, сохранение ответов – такие пожелания были взяты за основу при разработке QFI – Query Formulation Interface – Java приложения на стороне клиента системы UnIT-Net.
В статье представлены принципы создания такого интерфейса и его верификация.
Опубликовано в: «Mathematical Modeling, IT, Automated Control Systems» series of the Herald of Kharkiv National University, No 703, ISSN 0453-8048, p. 95-108
Теперь на страницах сайта SHCHERBAK.NET вы сможете познакомиться с статьями Дмитрия Павлова по OWL, нечетким онтологиям и их применениям в Semantic Web!
Дмитрий Павлов – исследователь и разработчик приложений для Semantic Web.
Его статьи вы сможете найти в рубрике “Дмитрий Павлов”.
Одну из первых статей Дмитрия Павлова «Задачи OWL-based поисковой системы и пути их решения» вы можете почитать здесь!
Павлов Дмитрий
Цель работы заключается в устранении критичности процесса поиска в распределенной онтологии. Поставленная цель, ввиду тенденций роста применения технологии 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 = Σ Stori, i=1,n, (2.1)
где Ont – распределенная онтология, Stori – часть онтологии, находящаяся в 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, query0).
Определение 1. Search(Ont, query0) возвращает наиболее полно описанную элементарную сущность языка OWL, отвечающую базовому запросу query0.
Под элементарной сущностью OWL мы понимаем класс, свойство либо объект, а под запросом query0 мы подразумеваем один из запросов указанных в 1.1 – 1.3.
Наиболее полное описание достигается только в результате работы с онтологией целиком. Чтобы не решать задачу поиска силами одного сервера обозначим порядок дифференциации нагрузки в рамках отдельных серверов, введем понятие локального поиска local_search(Stori, queryk).
Определение 2. Под локальным поиском мы будем понимать поиск, ограничивающийся ресурсами i хранилища данных.
Введем операцию-обработчик результатов process(Stori, result), где result - результат выполнения функции глобального либо локального поиска. Данная операция отвечает за преобразование результатов локального поиска в каскад запросов к серверам-соседям, узлам к которым ведут дуги от данного узла. По возврату данных от серверов-соседей может вновь инициироваться локальный поиск, но уже с учетом полученной информации.
Ввиду допущений 1 и 2, а также топологии сети, введем возможность перемещения поиска из узла, в котором происходит обработка информации, в узлы-соседи:
Stori ->{Stori1, … Storij}, (2.2)
где j число серверов-соседей активного узла.
Вновь имеем возможность применить глобальный механизм поиска, с центром в каждом из серверов-соседей. Получаем рекурсию, глубина которой для конкретного запроса равна максимальному пути, который можно построить из заданного узла (с учетом допущения 2). Из постановки задачи очевидно, что понятие поиска сразу распадается на три направления:
Рассмотрим каждое направление в отдельности.
Поиск по ссылке (1.1) – тривиальная техническая задача, в которой, имея имя узла и имя искомого на нем объекта, требуется получить развернутое описание объекта.
Поиск эквивалентного элемента (1.2) осуществляется путем использования стандартных рекомендаций для языка OWL[2].
Заполнение недостающего элемента в N-Triple (1.3) будем решать с помощью механизмов RDQL[9].
Не смотря на разобщенность направлений поиска, они тесно связаны. Рассмотрим взаимодействие механизмов поиска (Рис. 2-2).
search(Ont, [a,R,?] ) = Σ search(Ont, [am,Rn,?] ), m=1,M; n=1,N, (2.3)
где [a, R, ?] некоторый базовый запроса, am эквивалентно a, Rn эквивалентно R, M и N – количество найденных эквивалентностей соответствующему элементу N-Triple.
В 2.3 показано взаимодействие между поиском элементов эквивалентных данному (1.2), когда базовый запрос преобразуется в серию эквивалентных ему, и поиском недостающего элемента тройки (1.3). При формировании, как расширения запроса, так и при поиске недостающих элементов возможно возникает задача поиска по ссылке (1.1). Из сказанного следует, что в данном примере показана логическая связь всех трех элементарных типов поиска.
Рисунок 2-2 Взаимодействие механизмов поиска
3 Межсерверное взаимодействие
В основе межсерверного взаимодействия лежит технология агентного взаимодействия OWL-S[10]. Во-первых, ее использование формализует процесс передачи данных внутри сети, во-вторых, позволяет оставить возможность интеграции системы с внешними пользователями, еще не специфицированными на данном этапе разработки.
Для организации межсерверного взаимодействия специфицируется следующий интерфейс:
Используя данный интерфейс, были созданы следующие алгоритмы работы сервера, получившего запрос:
Предложенные алгоритмы при общем сходстве, имеют ряд концептуальных отличий и оптимальны в разных условиях. Алгоритм 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] 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.
Или что проиcходит когда технологии Web 2.0 объединить с Semantic Web…
Широкое развитие технологий Web 2.0 и социальных сетей привело к созданию новой концепции – Социальный Семантический Веб (Social Semantic Web).
Социальный Семантический Веб – это развитие концепции Semantic Web, в рамках которой социальные взаимодействия в Web можно использовать для создания семантически богатых (semantically rich) представлений знаний
К слову, семантически богатые знания (semantically rich knowledge) – это наиболее простая форма представления «поверхностных» знаний об объектах или процессах реального мира.
Read the rest of this entry »
Несколько лет назад открыл для себя замечательный ресурс SourceForge.NET. Меня, как разработчика и исследователя Semantic Web, этот ресурс не мог не заинтересовать. Этот ресурс просто кладезь структурированной информации о различных приложениях, в том числе и приложениях Semantic Web. Одних только проектов, связанных с онтологиями, в нем 185. Плюс 16814 проектов так или иначе связанных с Semantic Web.
Вообщем, этот ресурс может быть весьма полезен исследователям Semantic Web,- как минимум здесь Вы можете посмотреть, какие проекты уже разрабатываются и, главное, на какой стадии разработки находятся. Хочу отметить один немаловажный момент – как бы много Semantic Web проектов не было зарегистрировано на SourceForge.NET, большая часть из них не поддерживается или находится в такой стадии разработки, что просто нельзя их использовать в своих разработках. Но это о грусном!
В качестве положительных моментов – на SourceForge.NET могут быть найдены аннотации существующих Semantic Web проектов и, если повезет, их программная реализация и исходники 
Теперь можно читать анонсы новостей SHCHERBAK.NET на
http://shcherbak.livejournal.com/
Вы также можете вступить в клуб читателей моего сайта! Присоединяйтесь!
Для создания интерфейсов удаленного доступа (web-интерфейсов) к «файловым» онтологиям, реализованным, например, с помощью редактора онтологий Protégé, можно использовать ниже представленные компоненты:
Болячка под названием «грипп» настигла меня… Что же делать? А все оказывается просто. Берем медицинскую онтологию, загружаем ее в редактор онтологий Protege, ищем экземпляр «Грипп» объекта «Болезнь» (StringSearch справляется с задачей великолепно). Смотрим на структуру экземпляра «Грипп» – есть атрибут «лечение», множественные значения которого экземпляры объекта «Медицинский препарат». Так, есть парацетамол. Должно помочь!
Read the rest of this entry »
Функциональность редактора онтологий Protege(см. заметку) может быть расширена путем добавления плагинов.
Плагины к Protege можно разрабатывать самому, а можно воспользоваться одним из представленных ниже:
TGVizTab – плагин Protege, который позволяет визуализировать содержимое онтологии с помощью java библитеки TouchGraph. TGViz выводит графическое представление объектов, экземпляров и связей между объектами с возможностью контроля глубины вывода.
Вид онтологии в Protege, визуализированной с помощью TGViz:
Рекомендую для пользования!
Valentin Filatov, Sergey Shcherbak, Antonina Khairova
Abstract – The subject of the article is examination of storing large and stable ontologies in the spatial database, and also development of information storage and retrieval system of construction and supporting ontologies.
The article describes the method of storage large and stable ontologies with using systems of management of spatial data.
Keywords –Ontology, RDF(Recourse Description Framework), RDFS (RDF Schema), OWL (Ontology Web Language), Oracle Database 10g, Oracle Spatial
Due to the widening of Internet the work of searching systems has become harder, to provide sufficient coverage they had to index and process bigger volume of information. But the main difficulty was not even the increasing number of indexed web-sites, but providing users’ queries with relevant answers, i.e. giving them links to the resources they needed.
Present-day reality in individual areas of scientific exploration dictates the necessity of applying methods on knowledge engineering for solving wide class of practical goals. As an example there may be used the initiative of Semantic Web, the main aim of which is to give to large massive sod data, printed in the Internet, more sensible, to raise accommodation of working with the information.
One of the main achievements of Semantic Web project became the developing of ontology standard description language – OWL (Ontology Web Language). Thanks to this many knowledge engineers, programmers and experts got the possibility of using common rules of ontology conception, storage and processing.
There are different meanings of word ontology. In this article ontology is the specification of some data domain, it’s conceptual description as formalize conception, which includes vocabulary of terms of data domain and logical expressions describing intercommunications of these concepts. Thus, ontology of some data domain represents concepts thesaurus of this domain, providing the possibility of interpretation data domain terms via interpretation paradigmatic relations like “the whole and the parts”, “class – subclass” and some kinds of associative relations.
Together with the interests to the ontology the instrumentals for working with them were created, specially aligned for wide common use of ontology in the issues of intellectual searching, classification, and exposure of data non-coordination, modeling of behavior intellectual agents and processing of data. However, even presence of good instrumental environment doesn’t decline problems of ontology designing and constructing. And the problem of knowledge extraction automation just like the whole the problem of ontology extraction still doesn’t have an effective solution nowadays. Already developed ontologies and the experience of using them for solving different problems are becoming become more valuable.
The process of creating modern intellectual information systems often requires integration of knowledge from different sources, and as consequence effective solving of problems of knowledge replication. The problem of automation of choosing process still doesn’t have a satisfactory solution. That’s why studies on the developing such an approach for providing and replication of knowledge, which on one hand could allow to consider the specificity of data domain the most sufficiently and on the other hand – to provide and use knowledge in some uniform kind – are very important to present day.
Ontology models for the time of researching in this area have undergone considerable development. In the present time there are a lot of instruments for creating and supporting ontologies, which besides common functions of editing and oversight perform support of documentation ontology, import, export of ontologies in different formats, support of graphic editing, management of ontology libraries etc.
These tools of ontology constructing have several drawbacks. Most of the tools store their ontologies in text files, which limits size of ontology, the have low productivity, have superfluity of functions, that makes user’s work more difficult. The additional development of algorithms for comfort of working with stored metadata is needed.
Basing on the features of analysis of existing tools drawbacks, we can say that subject of the article is examination of storing large and stable ontologies in the spatial database, and also development of information storage and retrieval system of construction and supporting ontologies.
The article describes the method of storage large and stable ontologies with using systems of management of spatial data. During the realization f this module the following features of ontologies were taken into account: in ontologies knowledge is formalized as a description of data domain by means of class hierarchy; a separate set of features and objects is given for each class, features in ontologies have definitional domain – class, for which this feature is set, and also value area.
Depending on the value area the features are divided into two types: T-features (values of this data type or set of fated values) and o-features ( values of which are objects of fated class).
We can say, that the hierarchy structure on ontologies is projected on spatial structure of database. It is necessary to note that ontologies can be very big, in some cases besides complicate hierarchy with amount of classes and features there can be stored millions and millions of objects. In addition to this situation, when in one database great number of ontologies are stored, the speed of queries execution to database becomes lower. As the considered database is one of the parts of complicate project, in which access to database is performed very often, so that in general the speed of work execution depends on the speed of queries execution to database simpliciter.
Methods of application should allow putting information about data domain like ontologies in the spatial database, and also allow high speed of query execution. There should be methods for processing ontologies, classes, objects and features of objects, and also administration of database session in it.
As a result, it is necessary to draw attention, that the suggested methods of storage and support of ontologies in the spatial database and methods of their management are universal, which allows wide using of the results of this work in research and applied work.
Onlogies have been developed and used for solving different problems, including combined usage by people and program agents, possibility of accumulation and second knowledge use in data domain, creating models and programs, operating with ontologies, and not neatly specified structures of data, analysis of knowledge in the data domain.
For more intellectual generalization of sections of the information it is necessary for web-portals to define the ontology, which should describe the terminology used in contents of a web-portal, and the axioms setting rules of use of these terms in a context of other terms. Set of ontology and axioms is the model of the data description.
The base building block of data model is the statement representing a three: a resource, the called property and its value. In terminology RDF (Resource Description Framework) these three parts of the statement accordingly refer to: the subject, a predicate and object [5].
Everything that is described by means RDF is called a resource. It can be ordinary Web-page or its any part, for example, separate element HTML or XML, being a part of the described document. Also a resource can be the whole collection of pages, for example, separately taken Web-site. And, at last, something, not being accessible through the Internet can be resource, for instance, any subject from the world of things. In a word, everything that can attribute some URI (the universal identifier) or URI with addition of an internal name of object (a name of an anchor in HTML) can become a resource and be described by means of RDF.
It is necessary to understand a certain aspect, the characteristic, attribute or the attitude used for the description of a resource as property. Each property has the specific sense, admissible values, type of resources to which it can be applied, and also attitudes with other properties.
According to the specification, value of property can have one of two types. The first is the resource set by some URI. The second type – a literal – is some text value of the characteristic. However, the literal can express value of any primitive type of the data which are present in XML. It’s test also can comprise a certain marking, for example, XML, but distinctive feature of such marking is that it is not processed by the RDF-processor and is perceived as a usual line [6].
Real value RDF cannot be estimated, while it is used for the internal purposes of a separately taken application. There will be the use of RDF introduction, when it becomes means of interprograms interaction, data exchange when machines receive ability to combine the information received from various sources, thereby, receive any new information. The more applications on the Internet can work with data, the higher their value will be.
The description of technologies for development and support of ontologies.
The status of recommendation W3C and the presence of ready interoperability program decisions make Semantic Web technologies more attractive, than other technological decisions of knowledge engineering [7]. The key moment of the given approach is that besides the resources in our database metadata for the description of objects of storehouse and management by them, metadata, described by means of RDFS (Resource Description Framework Schema) language (fig. 1) are stored.
Fig.1 – Model of storage of metadata
The given approach is based on Oracle Spatial – data manager technologies Oracle Database 10g, including additional opportunities on processing spatial data for support of spatial services, different kinds of the GIS – applications intended for processing or granting of the information about the location of objects and other information systems.
Database Oracle 10g includes RDF/RDFS languages support, enabling developers of applications to use advantages of a platform of a semantic data structure. Applied developers can supplement value to data and metadata, defining new sets of terms and attitudes between them. These sets of terms («ontologies») are more adapted for realization of queries and the analysis based on the semantic approach, than usual data sets. The ontologic data sets often contain millions of data elements and attitudes between them which can be grouped in triplets, using new RDF model of data. Oracle supposes expansion to trillions of triplets for satisfaction of requirements of the majority of applications. What kind of storage principles of RDF has Oracle Spatial 10g?
• RDF data are stored as directed, logic graph;
• Subjects and objects are displayed as units, and predicates as ties at which the subject is the initial unit, and the object is final;
• Ties are a full RDF triplet;
• RDF the Data model supports three types of objects of a database:
• Model (RDF graph, that consists of a set of triplets);
• Base of rules (the set of rules);
• the Index of a rule (directed RDF graph).
Use of the proposed technology allows developers of a portal to create the uniform unified data presentation in all applications that will allow to find precisely the necessary information, simplify corporate data integration, reduce redundancy of data and provide unity of semantic values in all applications. All this, in turn, facilitates development, support and updating of applications within the limits of corporation.
The basic advantages of use Oracle Spatial 10g are:
• Integration of data from different sources without using of programming;
• Support of the decentralized management by data;
• Support of all RDF types of data;
• SQL search and restoration RDF of models;
• Realization of queries to RDF Models, with use of the scheme the graph;
• the Combination of queries RDF to others SQL operators;
• the Logic conclusion based on RDFS (RDF schemes) rules;
• The logic conclusion based on rules, defined by the user in the application.
In a basis of the proposed approach is active use of metaknowledge not only for the description of syntax and semantics of language of knowledge representation, but also for ontologies constructing, describing the basic kinds between concepts of problem area, and also model of the user of the system. However, as it was already marked in the introduction, designing and development of ontologies, that is ontologic engineering, is not a trivial problem. It requires the developers to have professionally the knowledge engineering technologies — from methods of extraction of knowledge before their structurization and formalization [8].
Nowadays for the majority of ontologies construction tools the following principles are typical: first of all, though the main part of similar systems has a visual component, it is necessary to type some constructions manually, that raises a level of requirements to the ontologies developer – before starting the work directly, the expert is compelled to waste time for studying the language of representation of knowledge; secondly, a part of tools realizes the certain functionality for performance of ontologies queries, but, unfortunately, have no unified interface for formation and performance of queries from external applications; thirdly, practically there are no ontology editors freely distributed and focused on the final user, which, naturally, slows down the development of all direction of ontology engineering.
During the development of the tool environment for the ontology developer we have tried to level minuses of analogues and to adopt their advantages. Any object of ontology has graphic representation (not only classes and individuals, but also properties, ties, etc.). The system is the independent application which is capable to represent itself as an ontology server. Now the editor completely supports designs of language of the ontology description RDF, work on expansion of its opportunities to language OWL is conducted. On fig. 2 the architecture of the appendix is resulted.
In this article we have paid special attention to the development of the effective application of processing, creation and management of ontologies.
Let’s note, that each copy in the world of ontologies is a member of class THING, so that each class defined by us automatically is subclass THING.
Fig.2 – Architecture of the developed system
Work of the user in system begins with creation of new data model. In the given model the user can create own ontology of a subject domain and in the further to edit it not mentioning other models. At the same time he has an opportunity at any moment to change current model of data and to start supporting another ontology or in general to remove model from base (fig. 3).
For ontology creation after model constructing the user passes on next tab «Classes». In the left part of page the hierarchy of classes in the form of a tree realized by means of technology ajax is located.
When choosing any class in the right part of the window the properties belonging the given class, and also specimens concerning to them (fig. 3) are displayed. Here there is an opportunity of addition and removal of a class. Also on this page the user can attach properties to the chosen class and to add or delete specimens of a class. All changes are brought in base as RDF – triplets.
On a tab «Property» the tree of properties is displayed, besides realization is based on technology ajax. In the given tree parental attitudes of properties to each other, i.e. hierarchy of properties are displayed. When choosing any property the tree of the instances showing their attitudes among themselves on given property.
On the given page there is an opportunity of addition of new property, removal of property and its editing. In property edition the user can change type of property (float, string, int, class), classes to which the given property can be attached, and also parents of property (fig. 4).
Fig.3 – Representation of classes, their copies and properties
The opportunity of the user independently to develop queries to a database is realized. Here we can combine usual sql queries with sparql queries. We shall consider a following example: to recognize all databases concerning to a class to spatial databases and to receive date of creation of base from other table. The given inquiry will look like that:
SELECT database_inf.createdate FROM database_inf, TABLE(SDO_RDF_MATCH(
‘(?m rdf:type :Spatial_database)
(?m :nameOfDatabase ?name)’,
SDO_RDF_Models(‘bk_sw_model’),
null,
SDO_RDF_Aliases(
SDO_RDF_Alias(»,sm_pkg.user_alias)),
null)
)t WHERE
sm_pkg.user_alias||database_inf.name=t.NAME
Fig.4 – the Window of editing of property
Using the function SDO_RDF_MATCH we get access to our database RDF of triplets. The first parameter is the basis sparql query, in which we particularly specify what we wish to receive, the second parameter is a model to which we address. The third parameter is the base of rules using which we get a possibility to make a logic conclusion .Fourth parameter is a space of model’s names. The fifth parameter is a filter, one of the parameters of sparql query. At first it is recommended to use parameter like “null” because for filter using it needs to be added into the rules base, which will be realized in the next version of the application.
The whole ontology of the defined data domain, as it was mentioned earlier, is stored in a database like RDF triplets. But triplets that are stored in any database do not bear any advantage, because the basis part of Semantic Web are search agents, on queries they receive some kind of the certain resource description in the form of the text file described on owl or as in our case on RDF language. In our system the module which gives out part of RDF document, describing required object, by query of the intellectual agent or other system (the query is made using the http protocol) is realized. The module also gives the list of all objects, the information about which is stored in system. Agent requests formed RDF document from database by the following address:
HTTP://<HOST_NAME>/<DATA_BASE_ACCESS_DESCRITION>/
<PROCEDURE_NAME>
<PARAMETERS_OF_QUERY>
The result of query of
http://localhost/apex/swagent?p=bk_sw the following rdf-document comes back:
<?xml version=»1.0″?>
<rdf:RDF xmlns:rdf=»http://www.w3.org/1999/02/22-rdf-syntax-ns#» xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema# xmlns:model=»http://swhost.kture/swstore/dbl#»>
<rdf:Description rdf:about=»http://swhost.kture/swstore/dbl#bk_sw»>
<rdf:type rdf:resource=»http://swhost.kture/swstore/dbl#Spatial_database»/>
<model:model rdf:resource=»http://swhost.kture/swstore/dbl#relational_mode»/><model:nameOfDatabase>bk_sw </model:nameOfDatabase>
</rdf:Description>
</rdf:RDF>
In this article the way of storage of large and stable ontologies, using technology Spatial Database Oracle 10g is considered. The use of Oracle Database 10g for data management which are marked by semantic marking language. It allows to allocate a set of advantages in comparison with management approaches based on files or on specialized databases. First of all there is low risk, high quality, productivity and safety in this approach.
As a result of the analysis of ontology storage and development existing systems of knowledge bases the following minuses [9] have been revealed:
• Data is stored in files;
• low productivity;
• development of additional algorithms for convenience of metadata storage;
• redundancy.
The information storage and retrieval system of ontology development and support has been developed for elimination listed mines above.
As a result of the full description of objects and their properties, the data domain is presented as the complex of hierarchical knowledge base. It is possible to carry out «intellectual» operations on it, such as semantic search and definition of integrity and reliability of data.
The basic advantages of the developed system are:
• convenient ontology storage in a spatial database;
• access to ontologies granted by a server via web-service, ontology preservation and extraction from depository;
• absence of converter from format RDF to the relational scheme and on the contrary realization necessity;
• use of objective ontology model, which represents concepts and attitudes from ontology in a user-friendly object-oriented interface;
• the convenient user interface;
• granting of the object description in a text kind on user query.
One of the minuses of system is the complexity of introduction. Format RDF has high complexity and it is not good for using by ordinary Internet users. Also this format does not allow to describe a data domain in corpore, therefore, support of the ontology description by OWL [5] will be stipulated in the future.
For many web-developers and programmers can be difficult to study RDF and OWL. Besides the main aim of the concept still is not known for many users. Work on popularization Semantic Web still is not finished, there are no practical examples.
The use of the proposed technology will allow ontology developers to create the uniform unified data presentation in all applications. It will allow to find precisely the necessary information, will simplify corporate integration of data, will reduce redundancy of data and will provide unity of semantic values in all applications. All this, in turn, facilitates development, support and updating of applications.
[1] Filatov V.A., Khairova A.A. Technology of the educational web-services organization on the base of XMLDB, HTMLDB, ORACLE SPATIAL // International scientific and technical magazine « Informational technologies and computer engineering » – Vinnitsa: VNТU. – 2007г. – Ed.. 1 (18) – p. 240 – 247.
[2] Collins H. Enterprise knowledge portals: next generation portal solutions for dynamic information access, better decision making and maximum results. – N.Y.: AMACOM, 2003. – p. 403.
[3] Sherback S.S., Khairova А.А. Developing of education web-services as effective strategy of development network study// Scientific – practice forum «Informatization of business by yang people: progressive technologies,science, business undertakings » (17th – 18th of may 2007). – Kharkov: KNEU, 2007. – p. 73 – 74.
[4] Filatov V.A., Khairova A.A. Research of methods and tools for development educational web – services. // 11-th International youth forum « Radio electronics and youth in ХХІ a century ». – Kharkov: KNURE, 2007. – p. 387.
[5] Berners-Lee, T. , Hendler, J., Lassilla O. The Semantic web – a new form of Web content that is meaningful to computers will unleash a revolution of new possibilities // Scientific American, May 2001.
[6] L.Stojanovic, J. Schneider, A. Maedche, S. Libischer, R. Studer, Th. Lumpp, A. Abecker, G. Breiter и J. Dinger. The role of ontologies in autonomic computing systems. – IBM Research Journal. 2004.
[7] Xavier Lopez, Susie Stephens, Jeam Ihm, Jayant Sharma, Melliyal Annamalai, Omar Olonso. Semantic Data integration for the Enterprise. March 2006.
[8] Ternier, S., Duval, E., Vandepitte, P. LOMster: Peer-to-peer Learning Object Metadata. In: P.Barker and S. Rebelsky (eds.) Proceedings of ED-MEDIA’2002 – World Conference on Educational Multimedia, Hypermedia and Telecommunications, Denver, CO, June 24-29, 2002, AACE – pp.1942-1943.
[9] Gavrilova T.A., Horoshevsky V.F. Knowledge base of intellectual systems: the Textbook for high schools. – SPb: «Peter», 2000.
УДК 519.7:007.52
Е.А. Жыжырий, С.С. Щербак
В статье предложен подход к организации поиска на основе онтологий предметных областей и разработано необходимое математическое обеспечение.
1. Введение
Развитие стандартов и широкая поддержка концепции Semantic Web крупными корпорациями определяет тенденции развития будущего Интернет как глобальной базы знаний, в которой программные агенты будут “осмысленно”, т.е. с учетом семантики, оперировать информацией для решения задач поиска и им подобных.
В рамках Semantic Web информация описывается в терминах объектов и свойств предметной области, спецификация которых задается с помощью специального вида словарей, называемых онтологиями предметных областей(ПрО).
Для представления знаний в онтологиях Semantic Web используется свойство-центричная модель. Главной особенностью этой модели является то, что объекты и свойства описываются отдельно. Причем, свойства описываются в терминах объектов, к которым они применимы, т.е. путем указания области применения (domain) и области значений свойства (range).
Для создания эффективных поисковых систем, основанных на онтологиях предметных областей, необходима разработка формальных процедур идентификации объектов ПрО на основе описаний, учитывающих накладываемые пользователем ограничения на значения свойств объектов.
2. Формальная модель онтологии предметной области
Поиск информации в рамках Semantic Web основывается на использовании знаний из онтологий ПрО. В рамках такого подхода содержимое документа представляется как совокупность экземпляров объектов ПрО, объединенных некоторым контекстом. Тогда поиск информации сводится к идентификации структурно-логических схем объектов ПрО в онтологиях и выводу экземпляров идентифицированного объекта с учетом пользовательских ограничений.
Структура объектов ПрО в онтологии явно задается с помощью структурно-логической схемы – совокупности формальных характеристик моделируемой объектом сущности ПрО.
Для организации поиска на основе онтологий ПрО создадим формальную модель онтологии ПрО и предложим процедуры ее обработки.
Уточним определения основных понятий используемых в работе.
Определение 2.1. Объект ПрО – формальная структура сущности предметной области.
Определение 2.2. Свойство объекта ПрО – логическая характеристика той или иной особенности объекта ПрО.
Определение 2.3. Онтология ПрО – спецификация распределенных по Web объектов ПрО и связей между ними.
Определение 2.4. Экземпляр объекта ПрО – объект ПрО с непустыми значениями свойств, связанный с другим объектом отношением “быть экземпляром” .
Свойство объекта ПрО, согласно определения 2.2, представим как совокупность следующих логических характеристик объекта ПрО:
|
p = < po, to, vo >, |
(2.1) |
где po – символьное имя свойства p объекта o, to – тип значения свойства,vo – значение свойства.
Объект ПрО, согласно определению 2.1, представим как следующую совокупность логических характеристик моделируемой сущности ПрО:
|
o = < N, P, S, D, I >, |
(2.2) |
где N – имя объекта, P – множество свойств объекта, причем 
, S – суперклассы объекта, D – подклассы объекта, I – экземпляры объекта, PU – множество свойств онтологии ПрО.
Множество отношений между объектами онтологии ПрО специфицируем с помощью следующего выражения:
|
R = < subclass, superclass, instance >, |
(2.3) |
где subclass – отношение «быть подклассом», superclass – отношение «быть суперклассом», instance – отношение «быть экземпляром класса».
Тогда иерархия объектов ПрО может быть представлена следующим образом:
|
Oi = < O, R > , |
(2.4) |
где O – множество объектов ПрО связанных между собой отношениями из R.
Учитывая вышесказанное, представим онтологию как совокупность структурно-логических схем свойств и объектов ПрО, связанных между собой отношениями R:
|
Ontology = < Oi, PU > , |
(2.5) |
где О – иерархия объектов ПрО связанных отношениями из R, а PU – множество свойств онтологии.
Структурно-логическая схема онтологии ПрО представлена на рис. 1.
3. Идентификация объектов предметных областей с учетом пользовательских ограничений
Задача организации поиска на основе онтологий ПрО в контексте Semantic Web приобретает следующий смысл – на основе сформированного пользователем описания строится запрос, в виде возможной структурно-логической схемы объекта ПрО с пользовательскими ограничениями на возможные значения атрибутов искомых объектов ПрО.
Рисунок 1. Структурно-логическая схема онтологии ПрО
Далее, по сформированной пользователем структурно-логической схеме объекта ПрО идентифицируется объект в онтологии путем сопоставления с существующими объектами онтологии. В случае, если идентификация успешна, т.е. найден объект онтологии соответствующий искомому, проводится вывод экземпляров идентифицированного объекта с учетом пользовательских ограничений на значения свойств.
Схема процесса идентификации объектов в онтологий ПрО представлена на рис. 2.
Рисунок 2. Схема процесса идентификации объектов в онтологии ПрО
Под идентификацией объектов ПрО будем понимать совокупность действий направленных на нахождение экземпляров интересующего пользователя объекта ПрО.
Последовательность идентификации объектов с учетом заданных пользовательских ограничений представлена ниже (рис.3):
Идентификация в онтологии объекта ПрО с структурно-логической схемой соответствующей структурно-логической схеме запроса
Вывод экземпляров объектов с учетом пользовательских ограничений на значения свойств.
Для организации идентификации объектов в онтологии ПрО введем понятие запроса к онтологии, что собственно и будет исходными данными для математической реализации метода идентификации объектов ПрО.
Определим запрос к онтологии как сформированную пользователем структурно-логическую схему объекта ПрО с установленными ограничениями на значения свойств экземпляров объекта таким образом:
Пусть pq – символьное имя свойства, rq – ограничение на значение ra = < ca, va >, тогда запрос Q к онтологии на идентификацию объектов ПрО с заданными пользователем ограничениями можно задать формулой:
|
Q = < N, < poq, <coq, voq > >,…,< pnq, < cnq, vnq > >, |
(2.6) |
где co, cn – условия вывода.
Рисунок 3. Схема процесса идентификации объектов с учетом заданных пользовательских ограничений
Процедура построения запроса к онтологии
Построение запроса к онтологии состоит из ниже перечисленных действий:
Указание символьного имени объекта ПрО, идентификацию экземпляров которого необходимо провести.
Выбор свойств объекта ПрО, значения которых интересны пользователю в контексте проводимого поиска.
Установка ограничений на значения свойств, т.е. определение критериев вывода экземпляров объектов ПрО.
Идентификация объекта ПрО, структурно-логическая схема которого соответствует пользовательскому запросу, заключается в следующем:
Пусть a = < N, P, O, O, O > структурно-логическая схема объекта ПрО, построенная по запросу Q, идентификацию которого необходимо провести, тогда запрос к онтологии подается на базовый объект онтологии, т.е. на такой объект, у которого нет суперклассов (N которого равно O) и вызывается процедура обработки
o этого объекта.
Процедура o сравнивает структурно-логическую схему запроса объекта, который ее вызвал и в случае полного совпадения прекращает обход объектов онтологии, иначе o передает запрос следующему объекту ПрО. В результате обхода графа онтологии процедура o возвращает реальный объект онтологии с искомой, задаваемой запросом, структурно-логической схемой объекта ПрО.
Для идентификации объекта ПрО, структурно-логическая схема которого соответствует пользовательскому запросу определим набор процедур, реализуемых в каждом объекте ПрО, необходимых для выполнения идентификации объектов в онтологии:
1. Процедура обработки объекта o
2. Процедура сравнения символьного имени объектов ПрО N
3. Процедура обработки пользовательского ограничения с
4. Процедура вывода экземпляров идентифицированного объекта 
5. Процедуры передачи запроса 
на объект o и с соответственно.
Рассмотрим более детально математическую реализацию каждой процедуры.
Процедура обработки объекта ПрО o..
Обработка объекта ПрО подразумевает выполнение ряда действий по сравнению символьных имен объектов ПрО и навигации по иерархии объектов ПрО.
В обязанности этой процедуры входит анализ поступившего запроса и выполнение той или иной процедуры в соответствии с содержимым запроса.>
Процедура обработки объекта ПрО o устанавливает соответствие между символьными именами объектов онтологии и запроса. Если соответствие установлено (
), то объект запроса идентифицирован и можно проводить вывод его экземпляров в соответствии с пользовательскими ограничениями на значения свойств; если соответствие не установлено, тогда необходимо проверить пустое ли множество подклассов объекта или нет – если пустое (
), то запрос передается следующему объекту ПрО этого уровня; если не пустое (
), то запрос передается на первый объект множества подклассов D.
Математическая реализация процедура обработки объекта ПрО o может быть представлена следующей формулой:
|
|
(2.7) |
где a = < N, P, O, O, O > – структурно-логическая схема объекта ПрО, построенная по запросу Q, идентификацию которого необходимо провести,
- возврат к объекту с которого был передан запрос (
) и передача следующему объекту (
), 
– процедура сравнения символьного имени объектов ПрО.
Процедура сравнения символьного имени объектов ПрО 
отвечает за сравнение символьных имен объекта онтологии и входящего запроса:
|
|
(2.8) |
где Naсимвольное имя объекта a, построенного по запросу Q, No- имя объекта ПрО, вызвавшего процедуру .
Процедура обработки пользовательского ограничения 
предназначена для обработки значений свойств экземпляров объектов на предмет соответствия пользовательским ограничениям, задаваемых в запросе Q.
Математическая реализация процедура обработки объекта ПрО c может быть представлена следующей формулой:
|
|
(2.9) |
где po – свойство идентифицированного объекта ПрО, to – тип значения свойства , 
– значение свойства идентифицированного объекта ПрО, 
– условие вывода пользовательского ограничения, 
– граничное значение свойства 
пользовательского ограничения.
Семантика действий «=» «>» «<» условия вывода определяется типом значения сравниваемого свойства, т.е. каким именно образом
c будет реагировать на символьные имена действий «=» «>» «<» определяется типом значения сравниваемого свойства.
Для целочисленного типа значений свойства действия «=» «>» «<» определим следующим образом:
«=» – сравнение целочисленных значений свойства запроса и анализируемого объекта на “равенство” и если значения равны, то вывод экземпляра в качестве результата;
«>» – вывод экземпляра объекта в качестве результата в случае если целочисленное значение свойства запроса больше целочисленного значения свойства анализируемого объекта;
«<» – вывод экземпляра объекта в качестве результата в случае если значение свойства запроса меньше значения свойства анализируемого объекта.
Для строкового типа значений свойств объекта ПрО под действиями «=» «>» «<» будем подразумевать следующее :
«=» – это сравнение значения свойства запроса и анализируемого объекта на “равенство” и если значения равны, то вывод экземпляра в качестве результата;
«>» – вывод экземпляра объекта в качестве результата в случае если значение свойства запроса
больше значения свойства анализируемого объекта 
, т.е. если является подстрокой и имеет место выражение 
;
«<» – вывод экземпляра объекта в качестве результата в случае если значение свойства запросаменьше значения свойства анализируемого объекта , т.е. если является подстрокой и имеет место выражение 
Действия «=» «>» «<» для значений свойств имеющих тип float (число с плавающей точкой) имеют такую же семантику как и соответствующие действия с целочисленным типом значений.
Процедура вывода экземпляров объекта
Вывод экземпляров идентифицированного объекта oid осуществляется путем последовательной обработки экземпляров объекта с учетом пользовательских ограничений, т.е. с проверкой соответствия значений свойств экземпляров на соответствие пользовательским ограничениям. В случае, если все значения свойств удовлетворяют пользовательским ограничениям, тогда экземпляр выводится в качестве результата выполнения запроса:
Пусть oid = < N, < po, to,vo >o,…,< pm, tm, vm >m > - структурно-логическая схема идентифицированного объекта oid,
Q = < N, < po, cor, vor > >o,…, < pm, < cou,vor >m > – структурно-логическая схема запроса с установленными пользовательскими ограничениями на значения свойств экземпляров объектов на заданных операциях cr = { <, >, = }.
Тогда подмножество экземпляров oid (
) с учетом пользовательских ограничений может быть получено последовательной проверкой каждого свойства экземпляра на предмет соответствия пользовательским ограничениям следующим образом:
|
|
(2.10) |
где o – объект ПрО, связанный с объектом 
отношением «быть экземпляром», I – множество экземпляров идентифицированного объекта , 
– свойство идентифицированного объекта , 
– тип значения свойства , 
- множество экземпляров I идентифицированного объекта .
Результатом идентификации объекта ПрО с учетом пользовательских ограничений будет подмножество экземпляров объекта 
, что собственно и необходимо было получить в контексте решаемой задачи поиска на основе онтологий ПрО.
Замечание. В случае если устанавливается более чем одно пользовательское ограничение (условие вывода на значения свойства) тогда решение о выводе экземпляра объекта как результата принимается как «положительная» конкатенация результатов сравнения отдельных значений свойств с ограничениями пользовательского запроса, т.е. если все значения свойств удовлетворяют пользовательским ограничениям, тогда экземпляр объекта может быть представлен как результат запроса[3].
4. Алгоритмическое обеспечение
Рассмотрим алгоритм реализации метода идентификации объектов ПрО на следующем примере:
Пусть задана онтология ПрО состоящая из 5 объектов – двух подклассов объекта Thing с экземплярами, как показано на рис 4.
Рисунок 4. Структурно-логическая схема онтология предметной области
Шаг 1. Построим запрос к онтологии Q на идентификацию экземпляров объекта B значения свойств b1, b2 которых равны 
:
Q = < B, <b1, <=,v2 > >,…,< b2, <=,v2 >>>
Шаг 2. По запросу Q построим структурно-логическую схему объекта a:
a = < B, P, 
, , >,
где P ={b1,b2}
Шаг 3. Подаем запрос на базовый объект Thing и вызываем 
этого объекта. Результат сравнения символьных имен объектов Thing и a будет отрицательным. Учитывая то, что множество подклассов D объекта Thing не пусто, то передаем запрос на первый объект множества его подклассов –
объект A.
Шаг 4. Вызываем объекта A. Результат сравнения символьных имен объектов A и a будет отрицательным; учитывая то, что множество D пусто, то передаем запрос следующему объекту – объекту B.
Шаг 5. Вызываем объекта B. Результат сравнения символьных имен объектов B и a будет положительным; учитывая это, далее вызываем этого объекта.
Шаг 6. Согласно выражения 2.10 результатом выполнения запроса будет объект 
.
5. Верхняя оценка сложности идентификации объектов ПрО в онтологии с учетом пользовательских ограничений
При идентификации объектов в онтологии ПрО используются следующие элементарные операции:
1. Операция символьного сравнения имен объектов;
2. Операция поиска свойства в списке свойств;
3. Операция сравнения значения свойства с ограничением запроса.
Операция символьного сравнения имен объектов используется при навигации по древовидной иерархии объектов. Верхняя оценка вычислительной сложности (ВОВС) этой операции будет следующая:
|
|
(2.11) |
где 
– число объектов в онтологии, 
- время затрачиваемое на выполнение операции.
Операция поиска свойств в списке свойств применяется один раз, когда объект идентифицирован и необходимо выбрать из списка свойств те свойства, которые принадлежат этому объекту. ВОВС этой операции следующее:
|
|
(2.12) |
где 
– среднее число свойств в объекте, 
- число свойств онтологии, 
– время, затрачиваемое на поиск одного свойства объекта.
Операция сравнения значения свойства с ограничением пользовательского запроса используется при выводе экземпляров идентифицированного объекта ПрО. ВОВС этой операции следующее:
|
|
(2.13) |
где 
– число свойств запроса с указанными пользовательскими ограничениями, 
- среднее число экземпляров объекта ПрО, 
– время, затрачиваемое на сравнение одного значения свойства с ограничением.
Учитывая вышесказанное, ВОВС идентификации объектов ПрО в онтологии с учетом пользовательских ограничениях при последовательном выполнении операций будет составлять:
|
|
(2.14) |
где 
– ВОВС операции символьного сравнения имен объектов, 
– ВОВС операции поиска свойств в списке свойств, 
- ВОВС операции сравнения значения свойства с ограничением пользовательского запроса.
Анализ выражения 2.14 с учетом 2.11-2.13 показывает, что наибольшее влияние на сложность алгоритма по критерию временных затрат оказывают параметры n и m. Учитывая то, что 2.14 является уравнением 1-го порядка, будем считать сложность полученного алгоритма идентификации линейной.
Проверим экспериментально полученную линейную сложность алгоритма идентификации.
Экспериментальные значения ВОВС идентификации (2.14), проводились на компьютере следующей конфигурации – процессор P4 2,4 ГГц с ОЗУ 512 MB.
Время, затрачиваемое на выполнение операций (2.11-2.13), в мкс (Табл. 2.1).
Табл. 2.1. Время затрачиваемое на выполнения операций
|
tn |
tk (мкс) |
tq (мкс) |
|
755,876 |
1203,368 |
3662,06 |
|
133,242 |
469,28 |
1272,922 |
|
145,812 |
207,824 |
1235,212 |
|
120,672 |
227,936 |
1231,022 |
|
120,672 |
197,768 |
1223,48 |
|
120,672 |
197,768 |
1231,022 |
|
113,13 |
191,064 |
1198,34 |
|
110,616 |
191,064 |
1251,972 |
|
120,672 |
197,768 |
1198,34 |
|
110,616 |
197,768 |
1271,246 |
|
110,616 |
191,064 |
1211,748 |
|
120,672 |
191,064 |
1244,43 |
|
110,616 |
204,472 |
1215,1 |
|
110,616 |
191,064 |
1244,43 |
|
110,616 |
201,12 |
1203,368 |
Средние значения времени, затрачиваемого на выполнение операций:
tn = 137,5661(мкс)
tk = 224,8522 (мкс)
tq = 1258,793 (мкс)
Экспериментальные значения ВОВС идентификации (2.15) в зависимости от параметров n и m представлены в Табл. 2.2.
Табл. 2.2.Экспериментальные значения ВОВС идентификации
|
N |
m |
Vid |
|
10 |
10 |
36804,41 |
|
20 |
20 |
47174,15 |
|
30 |
30 |
57543,9 |
|
40 |
40 |
67913,65 |
|
50 |
50 |
78283,4 |
|
60 |
60 |
88653,14 |
|
70 |
70 |
99022,89 |
|
80 |
80 |
109392,6 |
|
90 |
90 |
119762,4 |
|
100 |
100 |
130132,1 |
|
110 |
110 |
140501,9 |
|
120 |
120 |
150871,6 |
|
130 |
130 |
161241,4 |
|
140 |
140 |
171611,1 |
|
150 |
150 |
181980,9 |
|
160 |
160 |
192350,6 |
|
170 |
170 |
202720,4 |
|
180 |
180 |
213090,1 |
|
190 |
190 |
223459,9 |
|
200 |
200 |
233829,6 |
|
210 |
210 |
244199,4 |
|
220 |
220 |
254569,1 |
График зависимости сложности полученного алгоритма идентификации от параметров n и m представлен на рис. 5.
Рис 5. График зависимости сложности идентификации объектов ПрО от числа объектов и свойств в онтологии.
Проведенные эксперименты по вычислению сложности идентификации объектов ПрО подтверждают линейную зависимость между верхней оценкой вычислительной сложности идентификации объектов ПрО от числа объектов и свойств в онтологии.
Выводы
В работе показана специфика поиска на основе онтологий ПрО и предложен подход к решению этой задачи с соответствующим математическим и алгоритмическим обеспечением. Кроме того, в результате проведения экспериментальных исследований была получена верхняя оценка сложности идентификации объектов в онтологии ПрО с учетом пользовательских ограничений и построена зависимость сложности алгоритмического обеспечения метода идентификации от количества свойств и объектов в онтологии ПрО. А также было показано и экспериментально подтверждено то, что сложность алгоритма идентификации объектов ПрО является линейной.
Литература
http://w3c.org
http://www.ontolib.com
Филатов В.А., Щербак С.С., Хайрова А.А
Введение
С расширением Internet работа поисковых систем все более усложнялась: чтобы обеспечить достаточный охват, им приходилось индексировать и обрабатывать все больший объем информации. Но главная сложность заключалась даже не в увеличении количества индексируемых сайтов, а в том, чтобы обеспечить релевантные ответы на поисковые запросы пользователей, то есть выдавать пользователям ссылки на те ресурсы, которые, по их мнению, соответствуют тому, что они искали.
Современное состояние дел в отдельных областях компьютерных наук диктует необходимость привлечения методов инженерии знаний для решения широкого класса практических задач. Ярким примером тому является инициатива Semantic Web, основная цель которой – наделить огромные массивы данных, опубликованных в сети Internet большей осмысленностью, повысить удобство работы с этой информацией. Одним из главных достижений проекта Semantic Web стала разработка стандарта описания онтологий – OWL (Ontology Web Language), благодаря чему множество инженеров по знаниям, программистов и экспертов получили возможность использовать общие правила представления, хранения и обработки онтологий.
Существуют различные толкования самого понятия онтологии. В данной работе под онтологией понимается структурная спецификация некоторой предметной области, ее концептуальное описание в виде формализованного представления, которое включает словарь терминов предметной области и логические выражения, описывающее взаимосвязи этих понятий. Таким образом, онтология некоторой предметной области представляет собой тезаурус понятий этой предметной области, обеспечивающий возможность толкования терминов предметной области посредством интерпретации таких типов парадигматических отношений как «часть-целое», «класс-подкласс» и некоторых видов ассоциативных связей.
На волне интереса к онтологиям были созданы инструментальные средства и механизмы, специально ориентированные на широкое применение онтологий в задачах интеллектуального поиска, классификации, выявление несогласованности в данных, моделирования поведения интеллектуальных агентов. Однако даже наличие хорошего инструментального окружения не снимает проблем, связанных с трудностью проектирования и построения самих онтологий, а автоматизация процесса извлечения онтологий, как и в целом, задача извлечения знаний, и по настоящее время не имеют своего эффективного решения. Тем ценнее становятся уже разработанные онтологии и опыт их использования для решения широкого круга задач.
В процессе создания современных интеллектуальных информационных систем зачастую требуется интеграция знаний из разнородных источников и, как следствие, эффективное решение задач, связанных с тиражированием знаний. По-прежнему не имеет своего удовлетворительного решения проблема автоматизации процесса выбора адекватного специфике конкретной проблемной области и принятого в ней стиля рассуждения экспертов средства представления знаний. Поэтому и по сей день актуальны исследования, направленные на разработку такого подхода к представлению и тиражированию знаний, который с одной стороны позволял бы наиболее адекватно учитывать специфику проблемной области, а с другой – представлять и использовать знания в некотором унифицированном виде.
Актуальность и цель работы
Онтологические модели за время исследований в этой области претерпели значительное развитие. В настоящее время для создания и поддержки онтологий существует целый ряд инструментов, которые помимо общих функций редактирования и просмотра выполняют поддержку документирования онтологий, импорт и экспорт онтологий разных форматов и языков, поддержку графического редактирования, управление библиотеками онтологий и т.д.
Данные инструментарии построения онтологий обладают рядом существенных недостатков. Большинство инструментов хранит свои онтологии в текстовых файлах, что ограничивает размер онтологий, имеют низкую производительность, нужна дополнительная разработка алгоритмов для удобства работы с хранимыми метаданными, обладают избыточностью функций, что затрудняет работу пользователя.
Исходя из особенностей анализа недостатков существующих инструментариев, будем говорить, что тематикой статьи является рассмотрение проблемы хранения больших и стабильных онтологий в реляционной базе данных, а так же разработка информационно-поисковой системы создания и сопровождения онтологий.
Предлагается способ хранения больших и стабильных онтологий с помощью систем управления базами данных . При реализации данного модуля нам пришлось учитывать следующие свойства онтологий. В онтологиях знания формализуются в виде описаний предметной области с помощью иерархии классов. Для каждого класса задается свой набор свойств и объектов. Свойства в онтологиях имеют область определения – класс, для которого задается это свойство, а также область значений. В зависимости от областей значений свойства делятся на два типа: т-свойства (значениями которых являются константы заданного типа данных) и о-свойства (значениями которых являются объекты заданного класса).
Можно сказать, что иерархическая структура отологий проецируется на реляционную структуру баз данных. Следует понимать, что онтологии могут быть очень большими – в некоторых из них помимо сложной иерархии с множеством классов и свойств, могут храниться миллионы и миллионы объектов. В совокупности с ситуацией, когда в одной базе хранится множество онтологий, скорость выполнения запросов к базе данных сильно уменьшается. Так как рассматриваемая база данных является составной частью большого проекта, в котором обращение к базе происходит довольно часто, то от скорости выполнения запросов к базе напрямую зависит скорость работы приложения в целом.
Методы приложения должны позволить помещать в базу знаний информацию о предметной области в виде онтологий, а также обеспечивать высокую скорость выполнения запросов. В нем присутствуют методы работы с онтологиями, классами, объектами и свойствами объектов онтологий, а также управления сессией к базе данных.
Подводя итог, следует обратить внимание, что предлагаемый в данной работе способ хранения онтологий в реляционной базе и методы работы с ним являются универсальными, что позволяет широко использовать результаты предлагаемой работы в исследовательской и прикладной деятельности.
Семантическое описание данных
Онтологии разрабатываются и могут быть использованы при решении различных задач, в том числе для совместного применения людьми или программными агентами, для возможности накопления и повторного использования знаний в предметной области, для создания моделей и программ, оперирующих онтологиями, а не жестко заданными структурами данных, для анализа знаний в предметной области.
Для более интеллектуального обобщения разделов информации порталам необходимо определить свою онтологию, которая должна описывать терминологию, использующуюся в содержимом портала, и аксиомы, задающие правила использования этих терминов в контексте других терминов.
Базовый строительный блок модели данных – утверждение, представляющее собой тройку: ресурс, именованное свойство и его значение. В терминологии RDF эти три части утверждения называются соответственно: субъект, предикат и объект.
Ресурсом называют все, что описывается средствами RDF. Это может быть обыкновенная Web-страница или какая-то ее часть, например, отдельный элемент HTML или XML разметки, являющийся частью описываемого документа. Также ресурсом может быть целая коллекция страниц, например, отдельно взятый Web-сайт. И, наконец, в качестве ресурса может выступать нечто, не являющееся доступным непосредственно через Интернет, например, произвольный предмет из мира вещей. Одним словом, все, чему можно приписать некоторый URI (универсальный идентификатор) или URI с добавлением внутреннего имени объекта (имени якоря в HTML) может стать ресурсом и быть описано при помощи RDF.
Под свойством следует понимать некий аспект, характеристику, атрибут или отношение, используемое для описания ресурса. Каждое свойство имеет свой специфический смысл, допустимые значения, тип ресурсов, к которым оно может быть применено, а также отношения с другими свойствами.
Согласно спецификации, значение свойства может иметь один из двух типов. Первый – это ресурс, задаваемый некоторым URI. Второй тип – литерал – есть некоторое текстовое значение характеристики. Впрочем, литерал может выражать собой значение любого примитивного типа данных, присутствующего в XML. Его тест также может содержать в себе некую разметку, например, XML, но отличительной особенностью такой разметки является то, что она не обрабатывается RDF-процессором и воспринимается как обычная строка.
Реальное значение RDF невозможно оценить, пока он используется для внутренних целей отдельно взятого приложения. Польза от внедрения RDF будет тогда, когда он станет средством межпрограммного взаимодействия, обмена данными, когда машины получат способность комбинировать информацию, полученную из различных источников, тем самым, получая какую-то новую информацию. Чем больше приложений в Интернете смогут работать с данными, тем выше станет их ценность.
Описание технологий для разработки и сопровождения онтологий
Статус рекомендации W3C и наличие готовых интероперабельных программных решений делают технологии Semantic Web более привлекательными, чем другие технологические решения инженерии знаний.Ключевым моментом данного подхода является то, что кроме ресурсов в нашей базе данных хранятся так же метаданные для описания объектов хранилища и управления ими, метаданные описаны с помощь языка RDFS (рис. 1).
Рисунок 1 – Модель хранения метаданных
Данный подход основан на технологии Oracle Spatial 10g. Oracle Spatial – это технология СУБД Oracle Database 10g, включающая дополнительные возможности по обработке пространственных данных для поддержки пространственных сервисов, различного рода ГИС-приложений, предназначенных для обработки или предоставления информации о местонахождении объектов и других информационных систем.
СУБД Oracle 10g включает поддержку RDF/RDFS, давая возможность разработчикам приложений использовать преимущества платформы семантической организации данных. Прикладные разработчики могут дополнять значение к данным и метаданным, определяя новые наборы термов и отношений между ними. Эти наборы термов (”онтологии”) более приспособлены для осуществления запросов и анализа, основанного на семантическом подходе, чем обычные наборы данных. Онтологические наборы данных, часто содержащие миллионы элементов данных и отношений между ними, которые могут быть сгруппированы в триплеты, используя новую RDF модель данных. Oracle допускает расширение биллионам триплетов для удовлетворения требований большинства приложений. Какие же собственно принципы хранения RDF в Oracle Spatial 10g?
RDF данные хранятся как направленный, логический граф;
Субъекты и объекты отображаются как узлы, а предикаты как связи, у которых субъект является начальным узлом, а объект конечным;
Связи представляют из себя полный RDF триплет.
Oracle Spatial RDF Модель данных
RDF Модель данных поддерживает три типа объектов базы данных:
Модель (RDF граф, состоящий из набора триплетов);
База правил (набор правил);
Индекс правила (направленный RDF граф).
Использование предложенной технологии позволит разработчикам портала создавать единое унифицированное представление данных во всех приложениях, что позволит точно находить необходимую информацию, упростит корпоративную интеграцию и интеграцию данных, сократит избыточность данных и обеспечит единство семантических значений во всех приложениях. Все это, в свою очередь, облегчает разработку, поддержку и обновление приложений в пределах корпорации.
Основными преимуществами использования Oracle Spatial 10g:
Интегрирование данных из разных источников без применения программирования;
Поддержка децентрализованного управления данными;
Поддержка всех RDF типов данных;
SQL поиск и восстановление RDF моделей;
Осуществление запросов к RDF моделям, с использованием схемы графа;
Сочетание запросов RDF с другими SQL операторами;
Логический вывод, основанный на RDFS (RDF схемы) правилах;
Логический вывод, основанный на правилах, определяемых пользователем в приложении.
Разработка элементов программного обеспечения системы
В основе предлагаемого подхода – активное использование метазнаний не только для описания синтаксиса и семантики языка представления знаний, но и для формирования онтологий, описывающих основные виды взаимосвязей между понятиями проблемной области, а также модель пользователя системы. Однако, как уже отмечалось во введении, проектирование и разработка онтологий, то есть онтологический инжиниринг, не является тривиальной задачей. Он требует от разработчиков профессионального владения технологиями инженерии знаний — от методов извлечения знаний до их структурирования и формализации.
На сегодняшний день для большинства инструментальных средств построения онтологий характерно следующее. Во-первых, большая часть подобных систем хоть и имеет визуальную составляющую, однако некоторые конструкции приходится набирать вручную, что повышает уровень требований к разработчику онтологий – перед тем, как приступать непосредственно к своей работе, эксперт вынужден тратить время на изучение языка представления знаний. Во-вторых, часть инструментальных средств реализуют определенную функциональность для выполнения запросов к онтологиям, но, к сожалению, не имеют унифицированного интерфейса для формирования и выполнения запросов из внешних приложений. В-третьих, практически нет свободно распространяемых и ориентированных на конечного пользователя редакторов онтологий, что, естественно, замедляет развитие всего направления онтологического инжиниринга.
При разработке инструментальной среды разработчика онтологий мы постарались нивелировать минусы аналогов и перенять их достоинства. Любой объект онтологии имеет графическое представление (не только классы и индивиды, но и свойства, связи и др.). Система является независимым приложением, которое способно выступать в качестве сервера онтологий. В настоящее время редактор полностью поддерживает конструкции языка описания онтологий RDF, ведется работа по расширению ее возможностей до языка OWL. На рис. 2 приведена архитектура приложения.
Рисунок 2 – Архитектура разработанной системы
В данной статье авторы уделили особое внимание разработке эффективного приложения обработки, создания и управления онтологиями.
Заметим, что каждый экземпляр в мире онтологий является членом класса THING, т.о. каждый определенный нами класс автоматически является подклассом Thing.
Работа пользователя в системе начинается с создания новой модели данных. В данной модели пользователь может создавать свою собственную онтологию предметной области и в дальнейшем редактировать ее не затрагивая другие модели. В тоже время он имеет возможность в любой момент изменить текущую модель данных и приступить к сопровождению другой онтологии или вообще удалить модель из базы (рис. 3.1).
Для создания онтологии после создания модели пользователь переходит на следующую вкладку «Классы». В левой части страницы расположена иерархия классов в виде дерева реализованного посредством технологии ajax.
При выборе любого класса в правой части окна отображаются свойства, принадлежащие данному классу, а так же экземпляры относящиеся к нему (рис. 3). Здесь имеется возможность добавления и удаления класса. Так же на этой странице пользователь может привязывать свойства к выбранному классу и добавлять или удалять экземпляры класса. Все изменения заносятся в базу в качестве RDF – триплетов.
Рисунок 3 – Представление классов, их экземпляров и свойств
На закладке «Свойства» отображается дерево свойств, опять же таки реализация основана на технологии ajax. В данном дереве отображены родительские отношения свойств друг другу, т.е. иерархия свойств. При выборе любого свойства отображается дерево экземпляров, показывающее их отношения между собой по данному свойству (рис. 4).
Рисунок 4 – Окно отображения иерархии свойств и отношения экземпляров по свойству
На данной странице имеется возможность добавления нового свойства, удаления свойства и его редактирование. В редактировании свойства пользователь может изменить тип свойства (float, string, int, class), классы к которым данное свойство может быть привязано, а также родителей свойства (рис. 5).
Рисунок 5 – Окно редактирования свойства
Реализована возможность пользователя самостоятельно разрабатывать запросы к базе данных. Здесь мы можем совмещать обычные sql запросы с sparql запросами. Рассмотрим следующий пример: узнать все базы данных относящиеся к классу пространственным базам данных и получить дату создания базы из другой таблицы. Данный запрос будет выглядеть следующим образом:
SELECT database_inf.createdate FROM database_inf, TABLE(SDO_RDF_MATCH(
‘(?m rdf:type :Spatial_database) (?m :nameOfDatabase ?name)’,
SDO_RDF_Models(’bk_sw_model’),
null,
SDO_RDF_Aliases(SDO_RDF_Alias(”,sm_pkg.user_alias)),
null)) t WHERE sm_pkg.user_alias||database_inf.name=t.NAME
С помощью функции SDO_RDF_MATCH мы получаем доступ к нашей базе данных RDF триплетов. Первым параметром является основа sparql запроса, в котором мы конкретно указываем, что хотим получить, второй параметр – это модель к которой мы обращаемся. Третьим параметром является база правил, с помощью которой существует возможно производить логический вывод .Четвертый параметр – это пространство имен модели. Пятый параметр – это фильтр, который является одним из параметров sparql запроса. Рекомендуется для начала использовать null, т.к. для использования фильтра его нужно добавить в базу правил, которая будет реализована в следующей версии приложения.
Вся онтология определенной области, как упоминалось ранее хранится в базе данных в виде RDF триплетов. Но триплеты хранящиеся в какой-то определенной базе никакой пользы не несут, т.к. основой Semantic Web являются поисковые агенты, на запросы которых они получают своего рода описание определенного ресурса в виде текстового файла, описанного на owl либо, как в нашем случае на RDF языке. В нашей системе реализован модуль, который выдает часть RDF документа, описывающего запрашиваемый объект, по запросу интеллектуального агента или другой системы (запрос производится посредством http протокола). Модуль так же предоставляет список всех объектов, информация о которых хранится в системе
Адрес по которому агент из базы запрашивает rdf документ выглядит следующим образом:
http://<ИМЯ_ХОСТА>/<DatabaseAccessDescription>/<НАЗВАНИЕ_ПРОЦЕДУРЫ>< ПАРАМЕТРЫ ЗАПРОСА>
В результате запроса http://localhost/apex/swagent?p=bk_sw возвращается следующий rdf-документ:
<?xml version=”1.0″?>
<rdf:RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdfs=”http://www.w3.org/2000/01/rdf-schema#”
xmlns:model=”http://swhost.kture/swstore/dbl#”>
<rdf:Description rdf:about=”http://swhost.kture/swstore/dbl#bk_sw”>
<rdf:type rdf:resource=”http://swhost.kture/swstore/dbl#Spatial_database”/>
<model:model rdf:resource=”http://swhost.kture/swstore/dbl#relational_mode”/>
<model:nameOfDatabase>bk_sw</model:nameOfDatabase>
</rdf:Description>
</rdf:RDF>
Выводы
В данной статье был рассмотрен способ хранения больших и стабильных онтологий, с использованием технологии Spatial СУБД Oracle 10. Использование Oracle Database 10g для управления данными, которые размечены с помощью языка семантической разметки, позволяет выделить ряд преимуществ по сравнению с подходами управления основанными на файлах или на специализированных базах данных. Прежде всего это низкий риск, высокое качество, производительность и безопасность.
В результате анализа существующих систем хранения и разработки онтологических баз знаний были выявлены следующие недостатки:
хранение данных в файлах;
низкая производительность;
разработка дополнительных алгоритмов для удобства хранения метаданных;
избыточность.
Для устранения перечисленных выше недостатков была разработана поисково-информационная система разработки и сопровождения онтологий.
В результате полного описания объектов и их свойств предметная область представлена как сложная иерархическая база знаний над которой можно осуществлять «интеллектуальные» операции, такие как семантический поиск и определение целостности и достоверности данных.
Основными преимуществами разработанной системы являются:
удобное хранение онтологий в реляционной базе данных;
предоставление сервером доступа к онтологии через web-сервис, сохранение и извлечение онтологии из хранилища;
отсутствие необходимости реализации конвертера из формата RDF в реляционную схему и наоборот;
использование объектной модели онтологий, которая представляет понятия и отношения из онтологии в удобном для пользователя объектно-ориентированном виде;
удобный пользовательский интерфейс;
предоставление описания объекта в текстовом виде на запрос пользователя.
Одним из недостатков системы является сложность внедрения. Формат RDF обладает высокой сложностью и не рассчитан на применение рядовыми пользователями Internet. Так же данный формат не позволяет описать предметную область в полном объеме, поэтому в будущем будет предусмотрена поддержка описания онтологий посредством языка OWL.
Многим web-разработчикам и программистам бывает сложно освоить RDF и OWL. Кроме того, сам смысл концепции ещё не доведён до широких кругов пользователей. Работа по популяризации Semantic Web ещё не доведена до конца, не хватает практических примеров.
Использование предложенной технологии позволит разработчикам онтологий создавать единое унифицированное представление данных во всех приложениях, что позволит точно находить необходимую информацию, упростит корпоративную интеграцию и интеграцию данных, сократит избыточность данных и обеспечит единство семантических значений во всех приложениях. Все это, в свою очередь, облегчает разработку, поддержку и обновление приложений.
Список литературы
1. Филатов В.А., Хайрова А.А. Технология организации образовательных web-сервисов на основе XMLDB, HTMLDB, ORACLE SPATIAL // Міжнародний науково – технічний журнал «Інформаційні технології та комп’ютерна інженерія» – Вінниця: ВНТУ. – 2007г. – Вип. 1(18) – с. 240 – 247.
2. Филатов В.А., Хайрова А.А. Исследование методов и инструментальных средств для разработки образовательных web – сервисов.// 11-й Международный молодежный форум «Радиоэлектроника и молодежь в ХХІ веке». – Харьков: ХНУРЭ, 2007. – с. 387.
3. Berners-Lee, T. , Hendler, J., Lassilla O. The Semantic web – A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities // Scientific American, May 2001.
4. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем: Учебник для вузов. – СПб: «Питер», 2000.
5. Хайрова А.А. Использование XML-ориентированных технологий для разработки и поддержки образовательного WEB-портала // Программа и материалы XIII Международной студенческой научной конференции «Высшая школа Украины перед вызовами XXI столетия» (8 апреля 2006г.). – Харьков. НУА, 2006. – с. 134.
6. Collins H. Enterprise knowledge portals: next generation portal solutions for dynamic information access, better decision making and maximum results. – N.Y.: AMACOM, 2003. – с. 403.
7. Ternier, S., Duval, E., Vandepitte, P. LOMster: Peer-to-peer Learning Object Metadata. In: P.Barker and S. Rebelsky (eds.) Proceedings of ED-MEDIA’2002 – World Conference on Educational Multimedia, Hypermedia and Telecommunications, Denver, CO, June 24-29, 2002, AACE – pp.1942-1943.
8. Щебрак С.С., Хайрова А.А. Розроблення освітніх web-сервісов як ефективна стратегія розвитку мереженого навчання //Наукова – практична конференція «Інформатизація бізнесу очима молодих: прогресивні технології, наука, підприємництво» (17 – 18 травня 2007р.). – Харьков: ХНЕУ, 2007. – с. 73 – 74.
9.www.oracle.com/technology/tech/semantic_technologies
10. L. Stojanovic, J. Schneider, A. Maedche, S. Libischer, R. Studer, Th. Lumpp, A. Abecker, G. Breiter и J. Dinger. The role of ontologies in autonomic computing systems. – IBM Research Journal. 2004.
11. Xavier Lopez, Susie Stephens, Jeam Ihm, Jayant Sharma, Melliyal Annamalai, Omar Olonso. Semantic Data integration for the Enterprise. March 2006.
,
,
,
,
,
,
,
